The following is pasted from the $PDK_DIR/ncsu_basekit/doc/FreePDK45_Manual.txt file, included in the distribution:

==================================================================
Process: Generic 45 nm
Contents: FreePDK45 Manual
File: FreePDK45_Manual.txt
Created: June 4, 2007
==================================================================

Update History
   Date        who                   Details
------------------------------------------------------------------
2007-6-4       mdbucher    First version of manual, including
               & wdavis    notes on design rules and P-Cells.
2007-9-19      wdavis      Updated for version 1.1 of the kit.
2008-3-10      wdavis      Updated for version 1.2 of kit,
                           added section on HSPICE models
2011-4-7       wdavis      Updated for version 1.4 of kit.
               & hdemirc

------------------------------------------------------------------

***** Please send all questions and comments to eda_help@ncsu.edu! *****

Contents:

I.     Introduction
II.    Setup Files
III.   Design Rule Notes
IV.    LVS & PEX Notes
V.     P-Cells
VI.    HSPICE Models


--------------------------------------------------------------------------
I.     Introduction
--------------------------------------------------------------------------

This kit contains the technology library NCSU_TechLib_FreePDK45.  It
supplies techfiles, display resources, design rules and scripts to
permit layout design and rule checking for a generic 45 nanometer
process.  The technology information contained in this kit has been
compiled from published papers, predictive technology models and rule
scaling.  This information may be freely used, modified, and
distributed under the open-source Apache License (see the file
APACHE-LICENSE-2.0.txt in the root install directory for the complete
text).  Previous versions of this kit used the Gnu Public License
(GPL), but this was discontinued, because the user community felt that
GPL was too restrictive.

This technology is intended to work with the 45nm BSIM4 Predictive
Technology Model from Arizona State University
(http://www.eas.asu.edu/~ptm).  See the HSPICE Models section of this
file for details about these models.  Schematic creation and HSPICE
simulation for these models is supported through Cadence Virtuoso
and the Cadence Analog Design Environment (ADE), when using the
NCSU_Devices_FreePDK45 library, also distributed with this kit.

This manual is intended as an introduction to the kit, but it is by no
means comprehensive.  Please see the FreePDK Wiki for complete
documentation:

http://www.eda.ncsu.edu/wiki/FreePDK

--------------------------------------------------------------------------
II.    Setup Files
--------------------------------------------------------------------------

To use the kit, copy the following files from the cdssetup directory
to the directory where you start Virtuoso:

cdsinit             - Should be named .cdsinit
cds.lib             - Cadence Library Manager library list
lib.defs            - Open Access library list
.runset.calibre.drc - Calibre DRC runset file, with the rules path included.
.runset.calibre.lvs - Calibre LVS runset file, with the rules path included.
.runset.calibre.pex - Calibre xRC runset file, with the rules path included.
.runset.calibre.lfd - Calibre LFD runset file, with the rules path included.
                      (requires installation of LithoSim kit v1.2)

Sourcing the script setup.csh (in the cdssetup directory) will copy these 
files into the current directory if they do not exist and set the necessary
environment variables to ensure that they are used by Calibre Interactive.

--------------------------------------------------------------------------
III.   Design Rule Notes
--------------------------------------------------------------------------

The design-rules currently support layers up to and including metal 10.
See the "Layers" page on the FreePDK Wiki for a complete list of
layers.  These design rules are not comprehensive, but represent our
current state of understanding about how to design generic logic in
45nm for high yield.  Some design rules (such as antenna rules) are
still under development.

Design rule checking is currently supported with Calibre.  The drc rules
can be found in techfile/calibre/calibreDRC.rul.  See "Layout Tutorial #1"
on the NCSU EDA Wiki Tutorials page for an introduction on running 
Calibre DRC from Virtuoso.  There are currently no plans to support 
Diva for DRC.

See the "Design Rules" pages on the FreePDK Wiki for illustrations of 
all design rules, and the "Design Rule Development" page for notes on
how each rule was created.  Please also see the file 
FreePDK45_Release_Notes.txt for notes on specific design rule changes 
in this release.

---------------------------------------------------------------------------
IV.    LVS & PEX Notes
--------------------------------------------------------------------------

Layout vs. Schematic (LVS) Checks and Parasitic Extraction (PEX) are
supported for all metal layers and devices in the
NCSU_Devices_FreePDK45 library.  This functionality is supported with
Calibre.  The rules can be found in the calibreLVS.rul and
calibrexRC.rul files in the $PDK_DIR/ncsu_basekit/techfile/calibre
directory.  See "Layout Tutorial #2" on the NCSU EDA Wiki Tutorials
page for an introduction on running Calibre LVS and PEX from Virtuoso.

Currently, there is no variation information in the PEX rules.  All
extracted parasitics assume the widths and spaces as drawn, with
thicknesses, resistances, and permittivities given on the "Metal
Layers" page on the FreePDK Wiki.

-------------------------------------------------------------------------
V.     P-Cells
--------------------------------------------------------------------------

Two P-Cells are available in the NCSU_TechLib_FreePDK45 library,
named "nmos" and "pmos" with the extensions "_vtl", "_vtg", "_vth" and
"_thkox", indicating the four different types of supported devices.  
These P-Cells will generate design-rule correct layouts for NMOS and PMOS 
transistors.

These P-Cells are implemented with the CiraNova PyCell v4.2.5 plugin
for Virtuoso.  This plugin is available for free download from
http://www.ciranova.com.  It is known to be compatible with
Cadence Virtuoso 6.1.4 (OpenAccess 22.04.064).

In order to work properly, the PyCell environment setup must be
included in the Virtuoso environment setup.  See the file
cdssetup/icoa_setup.csh for an example setup script (not including the
required setup for this kit).  In addition, ensure that files
cnDloPcell.plg and cnPcellProxy.plg have been copied from the CiraNova
quickstart directory to the oa/data/plugins directory (which should be
located at the same level as the main Virtuoso installation
directory).  After performing these tasks, the PyCells should behave
like standard SKILL P-Cells.

--------------------------------------------------------------------------
VI.   HSPICE Models
--------------------------------------------------------------------------

These models were generated using the 45nm Nano-CMOS Predictive
Technology Model (PTM).  These models can be obtained directly from
http://www.eas.asu.edu/~ptm.  Many thanks to Kevin Cao at Arizona
State University for maintaining these models!  These models were 
tuned according to the Bulk-Si, poly-gate technology from Fujitsu
referenced below.  The performance of this technology is roughly
average among all published technologies investigated.

T. Miyashita, et al., "High Performance Low Power Bulk Logic Platform
Utilizing FET Specific Multiple-Stressors with Highly Enhanced Strain and
Full-Porous Low-k Interconnects for 45-nm CMOS Technology," IEDM, pp.
251-2544, 2007.

Four types of devices are supported, corresponding the low, general,
and high threshold voltage devices (VTL, VTG, and VTH).  These devices
were intented to roughly follow the high-performance, low operating
power, and low standby-power technologies respectively for the 2007
node in the 2005 International Technology Roadmap for Semiconductors
(ITRS), available at http://www.itrs.net.  There is also a thick-oxide
device (THKOX) for high-voltage off-chip IO.

Simulation of these models with a supply voltage of 1.0V yields the
following currents:

Nominal        VTL     VTG      VTH    |   VTL      VTG        VTH
                                       |
Ion   (uA/um) 1246   975.5      570    |  -801   -650.3     -379.2
Ioff  (nA/um)  100      10      0.2    |  -100      -10       -0.2
Igate (A/cm2) 15.3     6.2      0.8    | -14.4     -8.0       -0.6
                                       |
FF Corner      VTL     VTG      VTH    |   VTL      VTG        VTH
                                       |
Ion   (uA/um) 1325    1040      618    |  -854     -699       -408
Ioff  (nA/um)  229    21.8     0.38    |-205.4    -23.6      -0.39
Igate (A/cm2)   32    13.1      1.5    | -28.9    -15.9       -1.1
                                       |
SS Corner      VTL     VTG      VTH    |   VTL      VTG        VTH
                                       |
Ion   (uA/um) 1161     905      521    |  -750     -604       -351
Ioff  (nA/um) 43.1     4.6      0.1    |   -43     -4.4       -0.1
Igate (A/cm2)  6.4     3.3      0.4    |  -7.1     -4.0       -0.3



***** Please send all questions and comments to eda_help@ncsu.edu! *****

Introduction

The Parameterized Cells (P-Cells) in this kit are implemented with the PyCell Plugin for OpenAccess, available from Ciranova. In order to use the P-Cells, you must do the following:

1. Download and install PyCell Studio from Ciranova at http://www.ciranova.com. The root of this installation directory is generally set in the environment variable CNI_ROOT.
2. Create a modified setup script for Cadence Virtuoso that includes PyCell studio. See the file $PDK_DIR/ncsu_basekit/cdssetup/icoa_setup.csh (included with the FreePDK distribution) for an example script. This script will need to be modified, in order for it to work on your system.
3. Ensure that files cnDloPcell.plg and cnPcellProxy.plg have been copied from the $CNI_ROOT/quickstart directory to the oa/data/plugins directory (which should be located at the same level as the main Virtuoso installation directory).

After performing these tasks, the PyCells should behave like standard SKILL P-Cells.

Cadence Warnings

In more recent versions of Virtuoso, you will see the following warning messages when using these P-Cells:

 *WARNING* (DB-220704): The Pcell super master: NCSU_TechLib_FreePDK45/ 
  nmos_vtl/layout is not a SKILL super master. The usage of non-SKILL  
  Pcells in Virtuoso is not a supported feature.

To the best of our knowledge, these warnings do not indicate that the P-Cells are working incorrectly in any way.

What to do if Virtuoso Crashes

If Virtuoso crashes while using these P-Cells, first verify that you have completed all of the steps above. If Virtuoso continues to crash, then you probably need to re-compile the technology library.

Most of the effort in recompiling the kit is involved in setting up your environment and installation to run the gentech.py script. Follow these steps to make the necessary modifications.

1. Modify the file $PDK_DIR/ncsu_basekit/gentech/sshaft/setup.csh – The first change to make to this file is to change the PDK_DIR environment variable to match your installation path. The second change to to add the setup for Python, which will be used to run the compilaiton script. Note that there is a section of this file labeled “Setup Python 2.4”. From this point to the end of the script, the environment is being setup to run Python. It’s somewhat confusing, because there are many competing versions of Python on our computer system. You may safely delete all of this and replace it with a setup that works for you (or simply remove it, if you already have Python 2.4 or later in your environment). Note that there is a MUSE_HOME environment variable that is also defined, but this variable is used only in the Python setup and can be safely ignored.
2. Modify the file $PDK_DIR/ncsu_basekit/gentech/sshaft/src/py/Makefile – The first line of this file defines a variable SCRIPTPATH, which should be set to the path of your Python binary executable file.
3. Type “make” in this directory – This will copy each file to the ../../bin directory, add the Python path to the first line of each script in this directory, and set it’s mode to executable.
4. Update the Virtuoso/PyCell Setup Script – Next you will need to create a new setup script that adds both Cadence Virtuoso and CiraNova PyCell studio to your environment at the same time. Neither Cadence not CiraNova will show you how to do this. An example script is given in the file $PDK_DIR/ncsu_basekit/cdssetup/icoa_setup.csh. Modify this file, source it, and verify that you can start both virtuoso (e.g. “virtuoso &”) and PyCell studio (e.g. “pyros &”).
5. Modify the file $PDK_DIR/ncsu_basekit/gentech/sshaft/lib/py/setup.py – This file contains environment settings for various tools. We will now create the entries for this file to match your new Virtuoso/PyCell setup script. To do that, follow these steps:
   1. Login to a new shell with a clean environment. The commands here assume that you’re using a csh-style shell.
   2. Type “printenv > env1”
   3. Source your new Virtuoso/PyCell setup script
   4. Type “printenv > env2”
   5. Source the $PDK_DIR/ncsu_basekit/gentech/sshaft/setup.csh script
   6. Type “envparse.py env1 env2 setup.txt”. This will parse the differences between the env1 and env2 files and put the result in the file setup.txt.
   7. Insert the contents of the setup.txt file into the $PDK_DIR/ncsu_basekit/gentech/sshaft/lib/py/setup.py file, as shown below.

...
Env = {
  'cadence':{
(insert contents of setup.txt here, deleting the previous contents)
  },
  'synopsys':{
...

Finally you’re ready to run gentech.py. Change to the directory $PDK_DIR/ncsu_basekit/gentech and source the sshaft/setup.csh script (if you haven’t already, in the previous step). Then execute the command “gentech.py -log gen.log”. The “-log” argument is mandatory. It won’t work properly without it.

Assuming that all goes well, you should see the new technology library is compiled. One key way to note success is that the file $PDK_DIR/ncsu_basekit/lib/NCSU_TechLib_FreePDK45/tech.db should exist. Also, the gen.log file should look similar to the following:

Begin gentech.py
Executing: cngenlib -c --techfile /afs/eos.ncsu.edu/lockers/research/ece/wdavis/
users/wdavis/svn/freepdk45/trunk/ncsu_basekit/techfile/cni/Santana.tech pkg:pyce
lls  NCSU_TechLib_FreePDK45 /afs/eos.ncsu.edu/lockers/research/ece/wdavis/users/
wdavis/svn/freepdk45/trunk/ncsu_basekit/lib/NCSU_TechLib_FreePDK45 >& cngenlib.l
og
Creating run/cds/.cdsinit
Creating run/cds/cds.lib
Creating run/cds/lib.defs
Chdir run/cds
Writing command to exe.il: pdkAppendTechfile( ?stepargs list( "../../gen.log" t
5 1 "low"))
Executing: virtuoso -log CDS.log -nograph -replay exe.il
        Begin pdkAppendTechfile
        Loading "/afs/eos.ncsu.edu/lockers/research/ece/wdavis/users/wdavis/svn/
freepdk45/trunk/ncsu_basekit/techfile/FreePDK45.tf" into "/afs/eos.ncsu.edu/lock
ers/research/ece/wdavis/users/wdavis/svn/freepdk45/trunk/ncsu_basekit/lib/NCSU_T
echLib_FreePDK45"...
        Techfile successfully appended.
        Finished pdkAppendTechfile (elapsed time: 0h 0m 1s actual)
Step returned with value None
Chdir ../..
Executing: cp -r /afs/eos.ncsu.edu/lockers/research/ece/wdavis/users/wdavis/svn/
freepdk45/trunk/ncsu_basekit/techfile/customvia/* /afs/eos.ncsu.edu/lockers/rese
arch/ece/wdavis/users/wdavis/svn/freepdk45/trunk/ncsu_basekit/lib/NCSU_TechLib_F
reePDK45
Finished gentech.py (elapsed time: 0h 1m 14s actual)

Debugging the compilation

If something goes wrong, the first place to look is the gen.log file. This file will hopefully show the step where the error occurred and give you the name of the file to examine. If not, then the file will also show you the names of all log files generated during the compilation process. We may ask you to send us some of these files to help debug the problem.

The most common problem that occurs is that CiraNova makes a slight modification to the PyCell API, which requires some small change to the P-Cell code. We can help debug that change, but in order to do it, we will most likely need the contents of the file cngenlib.log.

Also, it would be helpful if you can give us the version numbers of the tools you are using:

• The Virtuoso version number is printed out at the top of the file CDS.log in your home directory.
• The PyCell Studio version number can be found in the file $CNI_ROOT/docs/version.txt
• The OpenAccess version numbers can be printed out with the command oaGetVersion.

Good luck! Please let us know if you have problems! Send e-mail requests to eda_help@ncsu.edu.

Name	Number	Description	Color (R,G,B #Hex)	Notes
active	1	Active Area	0,204,102 #00CC66	(2) (3)
nwell	2	n-type well implant	0,204,102 #00CC66	(1) (2)
pwell	3	p-type well implant	255,128,0 #FF8000	(1) (2)
nimplant	–	n-type source/drain doping	0,204,102 #00CC66	(2) (3)
pimplant	–	p-type source/drain doping	255,128,0 #FF8000	(2) (3)
sblock	–	Salicide block	0,0,255 #0000FF	(1) (2)
vthl	–	Low threshold implant		(3)
vthg	–	General use threshold implant		(3)
vthh	–	High threshold implant		(3)
thkox	–	Thick oxide		(3)
poly	–	Poly-silicon	255,0,0 #FF0000	(1) (2)
contact	–	Metal 1 contact to poly or active	128,38,38 #802626	(2) (3)
metal1	–	Metal 1	0,0,255 #0000FF	(1) (2)
via1	–	Metal 2 contact to Metal 1	–	(1)
metal2	–	Metal 2 (intermediate wires)	255,,0,255 #FF00FF	(1) (2)
via2	–	Metal 3 contact to Metal 2	–	(1)
metal3	–	Metal 3 (intermediate wiring)	0,255,255 #00FFFF	(1) (2)
via3	–	Metal 4 contact to Metal 3	–	(1)
metal4	–	Metal 4 (semi-global wiring)	255,255,204 #FFFFCC	(1) (2)
via4	–	Metal 5 contact to Metal 4	–	(1)
metal5	–	Metal 5 (semi-global wiring)	57,191,255 #39BFFF	(1) (2)
via5	–	Metal 6 contact to Metal 5	–	(1)
metal6	–	Metal 6 (semi-global wiring)	217,204,0 #D9CC00	(1) (2)
via6	–	Metal 7 contact to Metal 6	–	–
metal7	–	Metal 7 (thin-global wiring)	–	–
via7	–	Metal 8 contact to Metal 7	–	–
metal8	–	Metal 8 (thin-global wiring)	–	–
via8	–	Metal 9 contact to Metal 8	–	–
metal9	–	Metal 9 (global wiring)	–	–
via9	–	Metal 10 contact to Metal 9	–	–
metal10	–	Metal 10 (global wiring)	–	–

Notes

(1)	This layer was taken from the NCSU CDK [1]
(2)	This color was taken from the NCSU CDK [1]
(3)	This layer taken from input from CiraNova

References

[1]	NCSU, Cadence Design Kit, available online at http://www.cadence.ncsu.edu

Name	Pitch (Width/Space) (nm)	Thickness (nm) (1)	Resistivity (ohm/sq)	Permittivity	Via dimension (nm)	via resistance (ohm) (2)
ILD 9		2000		2.5	800	0.5
Global(9-10)	1600 (800/800)	2000	0.030 (3)	2.5
ILD 7-8		820		2.5	400	1
ThinGlobal (7-8)	800 (400/400)	800	0.075 (3)	2.5
ILD 4-6		290		2.5	140	3
Semi-global	280 (140/140)	280	0.21	2.5
ILD 2-3		120		2.5	70	5
Intermediate (2-3)	140 (70/70)	140	0.25	2.5
ILD 1		120		2.5	65	6
Metal 1	130 (65/65)	130	0.38	2.5
Poly-Dielectric		85		2.5	65	8
Poly	125 (50/75)	85	7.8	2.5

Notes

(1)	Thickness calculated from (Pitch/2) * Aspect Ratio, modified with data from reference 2.
(2)	In [7], CVD tungsten is assumed to have a resistivity of 20 uOhm-cm (200 Ohm-nm). The contact and via resistances are calculated from the length and width values of each via, assuming this resistivity.
(3)	Sheet resistances for global and thin-global metal are extrapolated from the value for semi-global metal, assuming the same material and an increase in thickness.

References

[1]	The International Technology Roadmap for Semiconductors (ITRS): Executive Summary, 2005 Edition, p. 5., available online at http://www.itrs.net
[2]	V. Arnal et. al., “45 nm Node Multi Level Interconnects with Porous SiOCH Dielectric k=2.5,” Proc. of the IEEE International Interconnect Technology Conference (IITC), pp. 213-215, June 5-7 2006.
[3]	V. Nguyen et. al., “An AnaIysis of the Effect of Wire Resistance on Circuit Level Performance at the 45-nm Technology Node,” Proc. of the IEEE International Interconnect Technology Conference (IITC), pp. 191-193, June 6-8 2005.
[4]	S. Narasimha et. al., “High Performance 45-nm SOI Technology with Enhanced Strain, Porous Low-k BEOL, and Immersion Lithography,” IEEE International Electron Devices Meeting (IEDM) Technical Digest, Dec. 11-13 2006.
[5]	H. Nii et. al., “A 45nm High Performance Bulk Logic Platform Technology (CMOS6) using Ultra High NA(1.07) Immersion Lithography with Hybrid Dual-Damascene Structure and Porous Low-k BEOL,” IEEE International Electron Devices Meeting (IEDM) Technical Digest, Dec. 11-13 2006.
[6]	N. Oda et. al., “Chip Level Performance Maximization Using ASIS (Application Specific Interconnect Structure) Wiring Design Concept for 45 nm CMOS Devices”, IEEE International Electron Devices Meeting (IEDM) Technical Digest, Dec. 5-7 2005.
[7]	I. Shao et. al., “An alternative low resistance MOL technology with electroplated rhodium as contact plugs for 32nm CMOS and beyond”, IEEE International Interconnect Technology Conference, pp. 102-104, Jun. 4-6 2007.

The manufacturing grid is 2.5 nm.

Notes

The manufacturing grid is the grid on which all design-rules are based. No shape may exist in the database that is not aligned to this grid.

Introduction

Layout vs Schematic verification (LVS) ensures that the connectivity of the physical design (the layout) matches with the logical design represented by the schematic or netlist. The inputs to Calibre LVS are an SVRF rule file, a layout netlist or database, and a source netlist or database. The LVS outputs that always occur include a run transcript and an LVS Report. A set of other results can also be generated.

Setup

Calibre LVS can be executed at command line as well as in a interactive mode. The interactive mode is easy to use and is explained below.

To use Calibre LVS, you need to follow the additional steps than one mentioned at Developer’s Getting Started Guide .At the “Start Cadence Virtuoso” step you need to set the varaible MGC_HOME as follows

setenv MGC_HOME /afs/bp.ncsu.edu/dist/calibre20061/

and then setup the environment and start Cadence Virtuoso and Calibre integrated with in it, using the following commands

add calibre
myadd myfp
myadd icoa
icfb &

In the CIW window, you should be able to see “Calibre Skill Interface” and some copyright information and that means the Calibre is loaded properly.

To run LVS

Open the layout you want to run LVS in Virtuoso Layout Editor.You should be able to see a menu option called Calibre Let the name of your layout be my_layout

Setup the layer map file which will be used while streaming the layout to GDII format. Goto Calibre-> Setup-> Layout Export and in the Layer Map File type in the location of the layer map file and select Show dialog before export (This is done so that every time you run LVS, this dialogue box opens and you can make sure that correct Layer Map file is being selected, otherwise LVS wont work correctly)

Next, goto Calibre -> Run LVS

Calibre Interactive – LVS window pops up

You get an option for specifying a Runset File Runset file is a file which has details about the various settings you need to specify and if you want a specific set of defaults, it can be saved in a runset file and loaded the next time you start off Calibre Interactive and saves you the trouble of specifying all the settings once again. The runset file will be saved in the directory you started ICFB, have a look at it.

Rules

Calibre -LVS Rules File – select the Calibre Rules file from the path Calibre – LVS Run Directory – select the directory from where you started ICFB

Inputs

select Hierarchial, Layout vs Netlist In the Layout tab Files : my_layout.calibre.gds Top Cell: my_layout Layout Netlist: my_layout.sp These options are already be filled in by the tool, leave them as it is Format: select GDSII and select the option “Export from layout viewer” (This is very important)

In the Netlist tab Files: my_layout.src.net Top Cell:my_layout These options are already be filled in by the tool, leave them as it is Format: select SPICE and select the option “Export from schematic viewer” (This is very important)

Outputs

Under the Report/SVDB

LVS Report File: my_layout.lvs.report svdb directory: svdb These options are already be filled in by the tool, leave it as it is Select View Report after LVS Finishes

Under SVDB database select “Create SVDB Database” and “Start RVE after LVS finshes”

Dont make any changes to Run Control

Then press Run LVS

Once LVS is completed, LVS report is opened automatically and RVE is also started.

Introduction

Design Rule Checking verification (DRC) ensures that the physical design (the layout) meets the required design rules. The inputs to Calibre DRC are an SVRF rule file and a layout database. DRC outputs include a run transcript and a DRC Report. DRC errors can be highlighted in the layout viewer.

Setup

Calibre DRC can be executed at command line as well as in a interactive mode. The interactive mode is easy to use and is explained below.

To use Calibre DRC, you need to follow these steps in addition to those mentioned in Developer’s Getting Started Guide . At the “Start Cadence Virtuoso” step you need to set the varaible MGC_HOME as follows

setenv MGC_HOME /afs/bp.ncsu.edu/dist/calibre20061/

and then set up the environment and start Cadence Virtuoso with Calibre integrated with it, using the following commands

add calibre
myadd pycell
myadd icoa
myadd myfp
icfb &

In the CIW window, you should be able to see “Calibre Skill Interface” and some copyright information and that means the Calibre is loaded properly.

To run DRC

Open the layout on which you want to run DRC in Virtuoso Layout Editor.You should be able to see a menu option called Calibre Let the name of your layout be my_layout

Next, goto Calibre -> Run DRC

Calibre Interactive – DRC window pops up

You get an option for specifying a Runset File The runset file has details about the various settings you need to specify. If you want a specific set of defaults, it can be saved in a runset file and loaded the next time you start Calibre Interactive to save you the trouble of specifying all the settings once again. The runset file will be saved in the directory where you started ICFB, have a look at it.

Rules

Calibre -DRC Rules File – select the Calibre Rules file techfile/calibreDRC.rul Calibre – DRC Run Directory – select the directory from where you started ICFB

Inputs

select Hierarchical In the Layout tab Files : my_layout.calibre.gds Top Cell: my_layout These options may already be filled in by the tool, so you can leave them as-is. Format: select GDSII and select the option “Export from layout viewer” (This is very important)

Outputs

Under the DRC Results Database

These options may already be filled in by the tool, so you can leave them as-is. File: my_layout.drc.results Format: ASCII Select ‘Start RVE after DRC finishes’ Select ‘Write DRC Summary Report File’ File: my_layout.drc.summary

Run Control

Leave these controls as they are.

Then press Run DRC

Once DRC is completed, DRC report is opened automatically and RVE is also started.

To view DRC errors in the layout viewer, select ‘Highlight All’ from the ‘Highlight’ menu in the DRC-RVE window.

 

Introduction

As the minimum feature size shrinks, optical effects in lithography play a larger part in yield. In order to model these effects and identify places in a layout where optical effects may affect functionality, we have inplemented a Calibre Litho-Friendly Design (LFD) rule deck. Using the LFD tool, the mask image of a layer is generated, then applied to an optical model which generates Process Variability bands. These PV bands represent the largest and smallest shape that is likely to print from the mask image. The LFD tool will flag errors where it is likely that the printed image will be problematic.

This kit is not included in the FreePDK base-kit distribution, because it would more than double the file-size. If lithography simulation catches on, then we may eventually include this kit as part of the base-kit distribution.

Installation

You must first install the FreePDK (at least version 1.2) in order to use the LithoSim Kit. Once that kit is installed, follow these quick steps:

• Download the file NCSU-LithoSim-FreePDK45-1.2.tar from below.
• Unpack the tarfile: “tar xvf NCSU-LithoSim-FreePDK45-1.2.tar”. The tar file contains a file called NCSU-LithoSim-FreePDK45-1.2.tar.gz. (You can verify the validity of this file using the instructions in the README file if you want to.)
• Move the file NCSU-LithoSim-FreePDK45-1.2.tar.gz file to the directory above where you installed the FreePDK and cd to that directory. You should see the “FreePDK45” directory in the current directoy’s listing.
• Execute the command “tar xzf NCSU-LithoSim-FreePDK45-1.2.tar.gz” from that directory. All files should be unpacked into the correct directories.

See the file README.LithoSim.txt in the root directory for a detailed list of the files included in this distribution.

[Download not found]

Running Calibre LFD

Calibre LFD can be executed just like Calibre DRC in interactive mode. The interactive mode is easy to use and is explained in the Layout Tutorial #4 – Lithography Simulation . This tutorial assumes that you have already worked through Layout Tutorial #1 – Introduction to Layout and DRC.

Please note that this kit has been designed to work with Calibre2007 and later.

 

Rule	Value	Description
WELL.1	none	saveDerived: nwell/pwell must not overlap
WELL.2	225 nm	Minimum spacing of nwell/pwell at different potential
WELL.3	135 nm	Minimum spacing of nwell/pwell at the same potential
WELL.4	200 nm	Minimum width of nwell/pwell

Rule	Value	Description
IMPLANT.1	70 nm	Minimum spacing of nimplant/ pimplant to channel
IMPLANT.2	25 nm	Minimum spacing of nimplant/ pimplant to contact
IMPLANT.3/4	45 nm	Minimum width/ spacing of nimplant/ pimplant
IMPLANT.5	none	Nimplant and pimplant must not overlap

Rule	Value	Description
ACTIVE.1	90 nm	Minimum width of active
ACTIVE.2	80 nm	Minimum spacing of active
ACTIVE.3	55 nm	Minimum enclosure/spacing of nwell/pwell to active
ACTIVE.4	none	saveDerived: active must be inside nwell or pwell

Rule	Value	Description
CONTACT.1	65 nm	Minimum width of contact
CONTACT.2	75 nm	Minimum spacing of contact
CONTACT.3	none	saveDerived: contact must be inside active or poly or metal1
CONTACT.4	5 nm	Minimum enclosure of active around contact
CONTACT.5	5 nm	Minimum enclosure of poly around contact
CONTACT.6	35 nm	Minimum spacing of contact and gate
CONTACT.7	90 nm	Minimum spacing of contact and poly

Rule	Value	Description
METAL1.1	65 nm	Minimum width of metal1
METAL1.2	65 nm	Minimum spacing of metal1
METAL1.3	35 nm	Minimum enclosure around contact on two opposite sides
METAL1.4	35 nm	Minimum enclosure around via1 on two opposite sides
METAL1.5	90 nm	Minimum spacing of metal wider than 90 nm and longer than 900 nm
METAL1.6	270 nm	Minimum spacing of metal wider than 270 nm and longer than 300 nm
METAL1.7	500 nm	Minimum spacing of metal wider than 500 nm and longer than 1.8um
METAL1.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um
METAL1.9	1500 nm	Minimum spacing of metal wider than 1500 nm and longer than 4.0 um

Rule	Value	Description
METALINT.1	70 nm	Minimum width of intermediate metal
METALINT.2	70 nm	Minimum spacing of intermediate metal
METALINT.3	35 nm	Minimum enclosure around via1 on two opposite sides
METALINT.4	35 nm	Minimum enclosure around via[2-3] on two opposite sides
METALINT.5	90 nm	Minimum spacing of metal wider than 90 nm and longer than 900 nm
METALINT.6	270 nm	Minimum spacing of metal wider than 270 nm and longer than 300 nm
METALINT.7	500 nm	Minimum spacing of metal wider than 500 nm and longer than 1.8um
METALINT.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um
METALINT.9	1500 nm	Minimum spacing of metal wider than 1500 nm and longer than 4.0 um

Rule	Value	Description
METALSMG.1	140 nm	Minimum width of semi-global metal
METALSMG.2	140 nm	Minimum spacing of semi-global metal
METALSMG.3	0 nm	Minimum enclosure around via[3-6] on two opposite sides
METALSMG.6	270 nm	Minimum spacing of metal wider than 270 nm and longer than 300 nm
METALSMG.7	500 nm	Minimum spacing of metal wider than 500 nm and longer than 1.8um
METALSMG.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um

Rule	Value	Description
METALG.1	800 nm	Minimum width of global metal
METALG.2	800 nm	Minimum spacing of global metal
METALG.3	0 nm	Minimum enclosure around via[8-9] on two opposite sides
METALG.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um
METALG.9	1500 nm	Minimum spacing of metal wider than 1500 nm and longer than 4.0 um

Subversion (SVN), like it’s predecessor CVS, is an open-source system for facilitating versioning of data when multiple users are working on the same project. Although it is intended primarily for software development, we recommend using it with Cadence design projects as well. This page details the practices that should be adopted in order to use Subversion with Cadence most effectively.

Major Differences between Subversion and CVS

For those coming to Subversion from CVS, there are a few kew differences that are helpful to know before jumping in (feel free to skip this if you are not familiar with CVS):

1. Subversion handles binary files just as easily as text files. There is no need to specify the “-kb” tag, as with CVS.
2. Unlike CVS, there is no environment variable that sets the repository. Instead, the repository URL is given when a repository is created, when files are initially imported, and when a tree is checked out. At all other times, Subversion gets the URL for the repository from the local “.svn” directory.
3. Subvsersion tracks directory structure as well as the files. This means that you typically check out an entire tree, rather than individual parts of a repository. It also means that new directories must be checked-in after they are added, just like regular files.
4. Subversion gives a revision number to the entire repository, rather than individual files. This means that you can check out the entire repository for any point in time with a single revision number.
5. CVS users generally use the command “cvs update” to check for modified files in a private source directory. This is not advisable with Subversion, because it will always merge changes. Instead, use “svn status” for this purpose. The Subversion status command gives a summary of all changes, rather than the detailed information with CVS.

Usage Policies and Maintenance

In order to allow the most freedom in viewing and using design-data created by other group member, we suggest the following policies:

• Anyone is free to check out the entire repository.
• In order to commit changes to the repository, you must have a login ID on the NCSU Unity system, and that ID must be in the list of developers. If you would like to get an NCSU Unity ID and/or be added to the list of developers, please contact Rhett Davis .
• Developers are free to create directories in the repository. Consult other developers for tips on the most logical location in the repository.
• Developers are free to modify other developers’ code. It’s not advisable to commit any changes, however, without consulting the author.

Checking Out the Repository

First, make sure that you have the executable “svn” on your system. I have been using SVN version 1.1.4 on Linux machines and version 1.4.5 with MS-Windows and Cygwin. So far, I haven’t noticed any problems mixing the versions.

I suggest checking out the repository with the steps below.

svn co https://svn.unity.ncsu.edu/osi/freepdk45/trunk freepdk45/trunk

This will check out the entire kit and put it in the subdirectory “freepdk45/trunk”. This is your Private Source Directory. If you want to check out a subtree (such as “ncsu_basekit” or “osu_soc”), I would suggest appending the directory name to the last argument above, so that the directory structure of your checked-out copy matches the repository directory structure.

Documentation

For more information, see the freely downloadable PDF “Subversion Book” at http://svnbook.red-bean.com.

Using Private Source Directories

Private source directories are where all users should do their work for the project. These directories are created by Subversion using the directions below. They can usually be identified by the fact that they always contain a subdirectory called “.svn”.

Updating a Private Source Directory

The “status” and “update” commands allows us to see what changes we have made and/or if other people have modified the repository. To see a summary of your changes, use the command

svn status

This will examine your directories and search for files that you have modified. If no changes have been made to a file, nothing will happen. If changes have been made, then you will see one of the following four characters printed before each filename:

1. M – Modified – You have locally modified this file from the version that was checked out.
2. A – Add – You scheduled this file to be added to the repository, but it has not yet been committed.
3. D – Delete – You scheduled this file to be deleted from the repository, but it has not yet been committed.
4. C – Conflicts – You updated this file (see below), and there were conflicts on the update.

Note that the “svn status” command does not need to access the network, so it will not check for changes from other users. If you want to see what files other users have modified, then use the “-u” option. This will print an asterisk “*” by the names of files that other users have modified. Alternatively, the “svn update” command does more than “svn status -u”, because it will actually load the changes from other users and attempt to merge your changes with other users’ changes.

svn update

If changes have been made to a file, then you will see one of the following six characters printed before each filename:

1. U – Update – You made no changes to the file, but someone else made changes to this file and committed them to the repository. An up-to-date version of the file is copied into your private source directory.
2. A – Add – Someone added this file to the repository since you last updated. An up-to-date version of the file is copied into your private source directory.
3. D – Delete – You made no changes to the file, but someone deleted this file from the repository since you last updated. Your copy is deleted. An up-to-date version of the file is copied into your private source directory. If you had made changes, this would not happen. Your changes would be saved.
4. R – Replace – You made no changes to the file, but someone deleted this file and added a new file with the same name since you last updated. An up-to-date version of the file is copied into your private source directory. This may seem redundant with U, but Subversion considers them to be different objects.
5. G – Merge – You made changes to the file, but someone else made changes to this file and committed them to the repository. You modified different parts of the file, however, and so Subversion was able to merge your changes with the other person’s changes successfully.
6. C – Conflicts – As with the Merge case above, Subversion attempted to merge your changes with the changes in the repository. This time was unsuccessful, however. Your private version is renamed with a “.mine” extension, and a new file is created with the original name that contains hints about where the conflicts lie. See fixing conflicts below. Generally, only text files can be merged successfully, so this feature seldom is useful with Cadence designs.

Note that if you want to “force” an update of a file that you modified (to throw away any changes that you have made), you can do so with the “revert” command:

svn revert [filename]

Note, however, that this does not get the most up-to-date revision of the file… it simply throws away your changes. You’ll still need to use “svn update” to get a most-recent copy.

Committing Changes

Once you’ve made changes to a file, you can “commit” (abbreviated “ci”) them with the command

svn ci [filename] -m "[log message]" 

The message doen’t have to be much, just enough to make life easy if you or someone else needs to fix conflicts later. Note that if you omit filename, all files in the current directory and subdirectory will be committed.

Note also that may need to enter your NCSU-Unity ID and password, depending on where you are running the command.

Examining Past Revisions

Use the following command to see a list of all repository revisions for a specific file or directory, along with the log message for each one.

svn log [path]

If you want to see the list of all revisions for the entire repository, then change to the root directory, and issue the command with no path argument.

Sometimes you may want to see a list of files that were changed for a specific revision. To do this, I generally do a diff between two revisions, and suppress the printing of the actual changes, so that only the filenames are listed. The command for this is

svn diff -rN:M --summarize

where N and M are the two revisions you want to check.

Adding New Files and Directories

It’s easiest to add new files and directories to the repository from an existing private source directory. Simply create the new file/directory and type

svn add -m "[description of file]" [file/directory name]

Unlike CVS, no special options are required to add binary files.

The new directory and all of its files and subdirectories will be recursively added to the repository. Other users won’t be able to see them, however, until you use the command “svn ci” to commit them.

Importing New Files and Directories

If you want to add a large number of files, it can be quite tedious to add them one by one. You can import a tree of files with the command

svn import [local path] https://svn.unity.ncsu.edu/osi/freepdk45/trunk/[repository path] -m "[message]"

All of the files and directories within the directory [local path] will be added to the repository directory [repository path]. Note that the directory given by [local path] will not be added unless you explicitly include it in the [repository path] argument. If you find that you have mistakenly imported something to the wrong place in the repository, then see “moving directories” below.

Note also that this does not turn [local path] into a private source directory. You will still need to check out the files you imported to create a private source directory, or simply use “svn update” to load the new files into an existing private source directory.

By convention, the first message is usually something simple, like “initial import”.

Moving Files and Directories

Because SVN manages directories as well as files, moving a directory in the repository must be done with the command

svn mv [oldpath] [newpath]

This command will copy the directory from oldpath to newpath without deleting the old directory. Once you commit the changes, the old directory will be deleted. The entire revision history will follow the files to the new location. You can also use this method to change the name of a file, if you want the revision history to be saved with the new file.

Examining Changes and Fixing Conflicts

If someone committed changes to a repository file that you were editing, the changes need to be merged. If you already know that someone made changes to your file, you can find out how many differences there are with the “diff” command:

svn diff [filename]

This command is similar to the normal UNIX “diff” command, except that it retrieves the most up-to-date revision from the repository for the second file. Note that this operation is not very useful for binary files. The command will print out lines from your private file with a preceeding “+” character and lines from the repository version with a “-” character. Lines with no preceeding character are there to help see the surrounding lines, but do not actually differ between the two files.

Otherwise, if you have arrived at this point because you used “svn update” and had conflicts, then Subversion automatically prints the results of the “diff” into the source file, with the characters “>>>>>>>”, “=======”, and “<<<<<<<” to delineate the differences. You would need to merge these differences yourself into a file that resolved the conflicts.

For your conveneince, Subversion also creates the following three files, whenever an update encounters conflicts:

• filename.mine – Your original file, before you issued the “svn update” command
• filename.rOLDREV – The old repository revision that you were editing
• filename.rNEWREV – The new revision that caused the conflicts

After resolving the conflicts, use the following command to remove these three files and let Subversion know that the file is no longer in a state of conflict.

svn resolved [filename]

You will still need to check in your changes, after using the “svn resolved” command.

Rolling Back to a Previous Version

If the changes are too much to deal with, then perhaps it’s best to just roll back to an earlier revision. To do this, first figure out the revision number that you want with the command

svn log [filename]

This prints out all revisions of this file and the log messages that were used when they were committed. Scan through the log entries and find the revision number that you want (something like “7”, for example). Then use the following command to retrieve that revision in your private source directory:

svn cat -r [revision number] [filename] > [filename]

The cat command pipes the file to standard out, which is then redirected into the file. This approach may seem verbose, but we would otherwise not be able to commit the old revision as the most-current one. Once you’ve looked the file over, you can commit the changes as before, making this old revision the new, most recent revision.

svn ci [filename] -m "[message]"

This page is intended for proposing and discussing new design rules. The rules are listed in the order that decisions were made, along with a brief rule description and one or more notes giving a rationale. When possible, key-words in the rule description are linked to a set of standard Verification Rule Types.

Rule	Value	Description	Notes
WELL.1	none	saveDerived: nwell/pwell must not overlap	(10)
WELL.2	225 nm	Minimum spacing of nwell/pwell at different potential	(10) (11)
WELL.3	135 nm	Minimum spacing of nwell/pwell at the same potential	(10) (11)
WELL.4	200 nm	Minimum width of nwell/pwell	(10) (11)
VT.1	none	Vt adjust layers must coincide with well
POLY.1	50 nm	Minimum width of poly	(1)
POLY.2	140 nm	Minimum spacing of poly AND active	(2)
POLY.3	55 nm	Minimum poly extension beyond active	(3)
POLY.4	70 nm	Minimum enclosure of active around gate	(10) (11)
POLY.5	50 nm	Minimum spacing of field poly to active	(10) (11)
POLY.6	75 nm	Minimum Minimum spacing of field poly	(14)
ACTIVE.1	90 nm	Minimum width of active	(4)
ACTIVE.2	80 nm	Minimum spacing of active	(4)
ACTIVE.3	55 nm	Minimum enclosure/spacing of nwell/pwell to active	(5)
ACTIVE.4	none	saveDerived: active must be inside nwell or pwell	(8)
IMPLANT.1	70 nm	Minimum spacing of nimplant/ pimplant to channel	(10) (11)
IMPLANT.2	25 nm	Minimum spacing of nimplant/ pimplant to contact	(10) (11)
IMPLANT.3/4	45 nm	Minimum width/ spacing of nimplant/ pimplant	(10) (11)
IMPLANT.5	none	Nimplant and pimplant must not overlap
CONTACT.1	65 nm	Minimum width of contact	(6)
CONTACT.2	75 nm	Minimum spacing of contact	(6)
CONTACT.3	none	saveDerived: contact must be inside active or poly or metal1	(8)
CONTACT.4	5 nm	Minimum enclosure of active around contact	(8) (12)
CONTACT.5	5 nm	Minimum enclosure of poly around contact	(8) (12)
CONTACT.6	35 nm	Minimum spacing of contact and poly	(10) (12)
METAL1.1	65 nm	Minimum width of metal1	(7)
METAL1.2	65 nm	Minimum spacing of metal1	(7)
METAL1.3	35 nm	Minimum enclosure around contact on two opposite sides	(13)
METAL1.4	35 nm	Minimum enclosure around via1 on two opposite sides	(13)
METAL1.5	90 nm	Minimum spacing of metal wider than 90 nm and longer than 900 nm	(16)
METAL1.6	270 nm	Minimum spacing of metal wider than 270 nm and longer than 300 nm	(16)
METALl1.7	500 nm	Minimum spacing of metal wider than 500 nm and longer than 1.8um	(16)
METALl1.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um	(16)
METAL1.9	1500 nm	Minimum spacing of metal wider than 1500 nm and longer than 4.0 um	(16)
VIA1.1	65 nm	Minimum width of via1	(8) (9) 15
VIA1.2	75 nm	Minimum spacing of via1	(8) 15
VIA1.3	none	saveDerived: via1 must be inside metal1	(8)
VIA1.4	none	saveDerived: via1 must be inside metal2	(8)
METALINT.1	70 nm	Minimum width of intermediate metal	(7)
METALINT.2	70 nm	Minimum spacing of intermediate metal	(7)
METALINT.3	35 nm	Minimum enclosure around via1 on two opposite sides	(13)
METALINT.4	35 nm	Minimum enclosure around via[2-3] on two opposite sides	(13)
METALINT.5	90 nm	Minimum spacing of metal wider than 90 nm and longer than 900 nm	(16)
METALINT.6	270 nm	Minimum spacing of metal wider than 270 nm and longer than 300 nm	(16)
METALINT.7	500 nm	Minimum spacing of metal wider than 500 nm and longer than 1.8um	(16)
METALINT.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um	(16)
METALINT.9	1500 nm	Minimum spacing of metal wider than 1500 nm and longer than 4.0 um	(16)
VIA[2-3].1	70 nm	Minimum width of via2	(15)
VIA[2-3].2	85 nm	Minimum spacing of via2	(15)
VIA[2-3].3	none	saveDerived: via2 must be inside metal2	(8)
VIA[2-3].4	none	saveDerived: via2 must be inside metal3	(8)
METALSMG.1	140 nm	Minimum width of semi-global metal	(7)
METALSMG.2	140 nm	Minimum spacing of semi-global metal	(7)
METALSMG.3	0 nm	Minimum enclosure around via[3-6] on two opposite sides	(13)
METALSMG.6	270 nm	Minimum spacing of metal wider than 270 nm and longer than 300 nm	(16)
METALSMG.7	500 nm	Minimum spacing of metal wider than 500 nm and longer than 1.8um	(16)
METALSMG.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um	(16)
VIA[4-6].1	140 nm	Minimum width of via4	(15)
VIA[4-6].2	160nm	Minimum spacing of via4	(15)
VIA[4-6].3	none	saveDerived: via4 must be inside metal4	(8)
VIA[4-6].4	none	saveDerived: via4 must be inside metal5	(8)
METALTNG.1	400 nm	Minimum width of thin global metal	(7)
METALTNG.2	400 nm	Minimum spacing of thin global metal	(7)
METALTNG.3	0 nm	Minimum enclosure around via[6-8] on two opposite sides	(13)
METALTNG.7	500 nm	Minimum spacing of metal wider than 500 nm and longer than 1.8um	(16)
METALTNG.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um	(16)
METALTNG.9	1500 nm	Minimum spacing of metal wider than 1500 nm and longer than 4.0 um	(16)
VIA[7-8].1	400 nm	Minimum width of via[7-8]	(15)
VIA[7-8].2	440 nm	Minimum spacing of via[7-8]	(15)
VIA[7-8].3	none	saveDerived: via[7-8] must be inside metal[7-8]	(8)
VIA[7-8].4	none	saveDerived: via[7-8] must be inside metal[8-9]	(8)
METALG.1	800 nm	Minimum width of global metal	(7)
METALG.2	800 nm	Minimum spacing of global metal	(7)
METALG.3	0 nm	Minimum enclosure around via[8-9] on two opposite sides	(13)
METALG.8	900 nm	Minimum spacing of metal wider than 900 nm and longer than 2.7 um	(16)
METALG.9	1500 nm	Minimum spacing of metal wider than 1500 nm and longer than 4.0 um	(16)
VIA[9].1	800	Minimum width of via9	(15)
VIA[9].2	880	Minimum spacing of via9	(15)
VIA[9].3	none	saveDerived: via9 must be inside metal9	(8)
VIA[9].4	none	saveDerived: via9 must be inside metal10	(8)
GRID.[1-26]	2.5 nm	Shapes on all layers must be on a 2.5 nm grid
ANTENNA.1	300:1	Ratio of Maximum Allowed (Field poly area or Metal Layer Area) to transistor gate area	(17)

This table contains proposed rules to be completed and deemed necessary before being added to the rules file.

Proposed Rule	Value	Description	Notes

Notes

(1)	50nm was chosen for the minimum width rectangle for poly, becasuse it is easier to design with than 45nm. It is assumed that the actual gate length is 45nm. In addition, the electron-micrograph in Fig. 18 in [3] appears to be about 50nm.
(2)	Poly gate spacing is listed as 140 nm in Table 1 of [3]. Examining the electron-micrographs in other papers, the spacing appears to be 75nm in [2] and 125nm in [1]. In order to be a conservative set of rules, we should probably set the rule to be the largest of the three (namely, 140nm).
(3)	Minimum poly extension beyond active varies from paper to paper, but appears to be on the order of the width of the poly line in most cases. Increased to 55 nm for manuracturablitiy based on advice from  ?????
(4)	Table 1 in [1] and Table 1 in [3] both list minimum active width of 60 nm and spacing of 80 nm. However, Anupama Subramaniam of Marvell suggests that active width should be at least twice the gate length for better yield (giving 90nm).
(5)	Min. spacing of N+ and P+ is listed as 102 nm in Table 1 of [2]. By setting the well/active enclosure/spacing to 55 nm, we effectively make this space 110 nm, which is slightly conservative and aligned to our 5 nm manufacturing grid.
(6)	Contact width/space is given as 66/74 in Table 1 of [1] and 60/80 in Table 1 of [3] (giving a pitch of 140 nm in both cases). We chose 65/75 because it is in the middle and aligned to the 5nm grid, while still offering a pitch of 140 nm.
(7)	Metal rules taken from the half/pitch values in table 1 of [2], which are nearly identical to the values in table 1 of [1] and table 4 of [3]. The only differences are that the width/space of metal1 are listed as 60/70 in [3] (still a pitch of 130 nm), and the global wiring has a pitch of 2000 nm in [1].
(8)	Rules are taken from an example Diva DRC file in the Diva reference.
(9)	Value taken from FreePDK45.tf, in which values were scaled down from an older technology.
(10)	Rule taken from the NCSU CDK.
(11)	Value taken from original MOSIS lambda-based rules.
(12)	Extension of active area beyond gate appears to be about 100nm in Fig. 10 of [1]. Given the contact size of 65nm, and as small an active enclosure as possible (i.e. 5nm), a 35nm space of contact to gate is implied.
(13)	Minimum via overlap value is taken from the 3-sigma overlay value in the 2005 ITRS for the 2007 technology node. This overlap is typically 2 times the overlay value. We have used 3 times this value and inflated it stightly to be conservative and to align to our manufacturing grid. Higher level metals do not have this requirement, so it is only applied to metal1 and the intermediate metal layers.
(14)	Anupama Subramaniam from Kevin Cao’s group suggested that field poly spacing should be 1.5 * poly half-pitch for improved yield.
(15)	Width/spacing modified to reflect minimum lower metal width, and to be similar to contact rules.
(16)	Variable width rules modeled off of GPDK version.
(17)	[4] cites that antenna ratios for 180nm technology generally limited to 1000:1. This is total antenna surface ratio and is defined in Fig. 7 in [4]. C. Gabriel thinks 1000:1 ratio maybe unsuitable for 45 nm technology. Blaze DFM site claims the ratio will drop, but not clear from the evidence if this is true or not. [5] claims that oxide charging plasma current is in the range of 100nA to 1uA and states that it is unlikely to increase much for tox below 1.5nm (i.e. Lg below 65nm). This is supported in [6] which concludes saying impact of plasma damage is negligible for ultra-thin gate oxide below about 1.5nm. A metal:antenna ratio 300:1 is chosen, where 300 times antenna area is the maximum allowed cumulative metal area from metal 1 to last metal layer, to be conservative.

References

[1]	H. Nii et. al, “A 45nm High Performance Bulk Logic Platform Technology (CMOS6)using Ultra High NA(1.07) Immersion Lithography with Hybrid Dual-Damascene Structure and Porous Low-k BEOL,” IEEE International Electron Devices Meeting (IEDM) Technical Digest, Dec. 11-13 2006.
[2]	S. Narasimha et. al., “High Performance 45-nm SOI Technology with Enhanced Strain, Porous Low-k BEOL, and Immersion Lithography,” IEEE International Electron Devices Meeting (IEDM) Technical Digest, Dec. 11-13 2006.
[3]	E. Josse et. al., “A Cost-Effective Low Power Platform for the 45-nm Technology Node,” IEEE International Electron Devices Meeting (IEDM) Technical Digest, Dec. 11-13 2006.
[4]	C. T. Gabriel and E. de Muizon, “Quantifying a simple antenna design rule,” 5th International Symposium on Plasma Process-Induced Damage, May 22-24 2000.
[5]	D. S. Bang et. al, “Effect of Cu damascene metallization on gate SiO2 plasma damage,” 3rd International Symposium on Plasma Process-Induced Damage, Jun. 4-5 1998.
[6]	W. T. Weng et. al, “A Comprehensive Model for Plasma Damage Enhanced Transistor Reliability Degradation,” 45th Annual International Reliability Physics Symposium, 2007.

Creating a Distribution of the Base-Kit

To create a new distribution of the base-kit, follow these steps:

1. Make sure that the kit version number and repository revision number are up-to-date in the README.txt file at the top of the distribution. The revision number can be checked with the command svn update from a private source directory.
   • If the repository revision number is not correct, then increment it in the README.txt file and check it in again. Remember that it should be incremented to a value one higher than the result of the svn update command, so that the number is correct after it is checked in.
2. Change to a new, empty directory and export the current contents of the repository with the command

    svn export https://svn.unity.ncsu.edu/osi/freepdk45/trunk

3. Rename the root directory from trunk to FreePDK45.
4. Compile the kit according to the directions on the FreePDK45:Developer Getting Started page. Do not run genlitho.py. It’s not needed for the base-kit.
5. Run through the regression tests on the kit to make sure that it’s working. Currently, these tests include the following: (NOTE these should be automated, but they haven’t been)
   • Running Calibre DRC on the layouts in $PDK_DIR/ncsu_basekit/examples/DRC_Test
   • Running Calibre LVS and PEX on a simple inverter layout
6. From the root directory of the distribution, type the command

   source ncsu_basekit/doc/remove-list.csh

   This will delete all detritus from the distribution, as well as files that are included in the LithoSim kit.

7. Change up one directory to the directory containing the root. Then type the command

   tar czf NCSU-FreePDK45-X.X.tar.gz FreePDK45

   where X.X is the current version number.

8. Send the file to Steve Lipa for posting on the Wiki (we’ll get instructions for him on how to do that, eventually).

Creating a Distribution of the LithoSim Kit

To create a new distribution of the LithoSim, follow these steps:

1. Make sure that the kit version number and repository revision number are up-to-date in the README.LithoSim.txt file at the top of the distribution. The revision number can be checked with the command svn update from a private source directory.
   • If the repository revision number is not correct, then increment it in the README.LithoSim.txt file and check it in again. Remember that it should be incremented to a value one higher than the result of the svn update command, so that the number is correct after it is checked in.
2. Change to your private source directory and run the genlitho.py script, as described on the FreePDK45:Developer Getting Started page.
3. Create a new, empty directory somewhere and name it FreePDK45.
4. Copy the files mentioned in the README.LithoSim.txt into this directory, recreating the paths as needed. We should probably have a script to do this for us.
5. Change up one directory to the directory containing the root. Then type the command

   tar czf NCSU-LithoSim-FreePDK45-X.X.tar.gz FreePDK45

   where X.X is the current version number.

6. Test the distribution. Unpack the latest FreePDK base-kit to a new directory and unpack the file you just made to the same directory. Verify that you can run a lithography simulation.
7. Send the file to Steve Lipa for posting on the Wiki (we’ll get instructions for him on how to do that, eventually).

Response Suface Methodology Tutorial

• Introduction

This tutorial will introduce you to the Synopsys Taurus TCAD environment and the flow to perform Design of Experiments (DoE)/Response Surface Methodology (RSM) along with hspice simulations to understand the effects of process variations on circuit perfomance.

Due to deep sub-micron IC technology and scaling to finer feature sizes, it becomes increasingly difficult to control the process variations. This as resulted in device characteristics to be more sensitive to these process variations and thus increased the uncertainty in circuit performance. Hence, effective modeling and predicting the statistical variations of the circuit performances and redesigning to meet the performance specifications is a very important task.

Worst case and best case SPICE models are used by the designers to verify the design at the extremes of process variations. In this case, increasingly significant intrinsic correlations among physical parameters are not sufficiently considered and produce circuit performances that are overly pessimistic (or optimistic). One of the methods to overcome this problem is to perform Monte-Carlo Simulation for a given circuit. This method becomes computationally expensive and impractical for large circuits.

To overcome the limitations of Monte-Carlo Simulation, RSM along with DoE will be used.

To perform the DOE and RSM, we will use the Taurus Workbench from Synopsys where as the hspice simulations will be carried out using a script.

• Setup

Start the Synopsys TCAD

% add synopsys_tcad
% twb -use_dfm &

Note: We need to start taurus workbench with -use_dfm option to use the RSM feature.

The first window that appears is called the Workspace window.

Create a new project by selecting Project->New. Projects are shown as columns. Each project has a library (a cell with the book icon) and a list of experiments. Each library also contains simulation components(Modules/Tools/Drivers) for reuse in other projects. An experiment consists of a Process Recipe, a Wafer Flow, and all the associated simulation data.Access to a given project is indicated by the book icon; if a pencil is on the book,you have write-access, otherwise, theproject is read-only. In the initial Workspace window you see three read-only projects: templates,standard and dfm_work.

(The project can be renamed by right-clicking on the library and Edit name)

Once you create a new project, you can copy experiments from the read-only libraries. To do this:

1. Select a cell with an experiment’s name by clicking on it.
2. Drag and drop it into your project.

A warning notice offers a choice of Deep or Shallow copy as shown below

Do a Shallow copy of the library hspice_baseline from dfm_work project and rename it. We will be using this experiment as our starting point and editing it to our requirements.

To edit the newly created experiment “Expt1”, double-click the cell containing the experiment name. An experiment window opens, as shown below

To view the contents of a module “hspice_test”, double-click the module object. A Module editor opens

We can delete the inbuilt Command “circuit” by selecting the particular cell and Command->Cut. Lets create a new command called “RSM” by Command->New->Append. You will get the following warning, choose “Destroy”

Lets consider an example of a two stage two input Standard Cell Inverter (INVX1). The setup allows us to analyze the effects of process variations considering each of the transistors in the circuit suffer different variations. The parameters that are currently supported whose variation effects can studied are Leff, Tox and Vth.

In this example, Leff is assumed to vary by +/-10% of the nominal value. So we need to DOE for 4 parameters of Leff (one for each of the transistors) This is done by Parameter->New->Append and enter the corresponding values in each window as shown below.

1) The name (Leff1, Leff2.. Tox1, Tox2,.. and Vth1, Vth2,.. so on) and nominal value of the parameter (separated by an = sign).
2) The Parameter label, which is used to reference a parameter value ( % followed by parameter name).
3) The Min/Max fields - values depending on the percentage of variations.
4) A Control checkbox to designate a control parameter (Check this so that this parameter can be accessed in DOE).

We can similarly add other parameters.

Also, we need to add a parameter for response (for ex – delay, power). Multiple responses can also be entered. The min/max value can be 0/1 as it does not matter and do check the Control checkbox for this parameter also. Lets add two responses – tdelayLH and tdelayHL.

In the Experiment window, click on the “Run Table…” under the Edit tab. The following window opens and rest of the procedure is done from this window

To perform DOE click on the “DOE…” tab and make sure you have ticked all the parameters required for DOE under the “Design” column as show above (NOTE – Do not check the responses, tdelayLH and tdelayHL in this case). A new DOE window opens as shown below.

You can select the required DOE, change the levels and say “Build Design”. You might get the below warning, proceed to say yes.

Once the design is built, you will get a message “New Design has been built” and the sampling points generated from this DOE can be accessed by clicking on the “Spread Sheet…” in the Experiment window. Now check the responses also so that it gets reflected in the spread sheet as shown below.

Save this file as .txt by File->Save

The responses from the simulations using these values as inputs, will be appended to this spreadsheet and used to perform RSM.

• HSPICE Simulations

A automation script: RSMFlow.pl is used to do the following –

*To use each set of values in the DoE file as inputs to create different PTM models.
*Use these PTM models to simulate a netlist of a circuit using hspice.
*To capture the response of the circuit in every simulation run and to update the response of DoE spreadsheet so that it can be used to perform RSM.

To use the RSMFlow.pl script, the following must be present in the current working directory

Automation script – RSMFlow.pl Netlist of the circuit – .sp file DOE file generated by Taurus Workbench – .txt file PTM directory – Create a directory by name “PTM” (shoould have the two files called NMOS_last PMOS_last) and a sub-directory called “doc” . With in this doc directory, the created PTM models are stored.

NOTE: Makesure you do “add hspice” in the terminal window before you run RSMFlow.pl.

Usage of RSMFlow.pl

perl RSMFlow.pl -help

Will show the help for this flow as :

[NOTE]: Makesure you do " add hspice " in the terminal window before you run RSMFlow.pl
To run this flow,the inputs needed are:
The Hspice Netlist file (-netlist)
The DoE File (-doe)
The Design Factors can be Vth, Leff, Tox. If any of the factors is not used, its value must be zero,
else should indicate the order it is present in the DOE spreadsheet
The number of responses in the Experiment (-res)
If the factors is assumed to vary by the same amount for all tranistors in the netlist
then set (-multi) to 0, otherwise 1
The Name of the output DoE file with the responses appended (-output)
Ex: " perl RSMFlow.pl -netlist INVX1.sp -doe DOEINVX1.txt -vth 0 -leff 1 -tox 0  -res 2 -multi 1 -output ResDOEINVX1.txt

A brief explanation of the inputs to the RSMFlow.pl and its working.

The hspice netlist file which needs to be simulated is given as input using the -netlist option and the DOE file with -doe option. In this ex, since only Leff is being used,value of option -leff is 1 and -vth,-tox are 0. If Leff and Tox were varied in this experiment and if Leff was entered first in the module window, then the options would be -vth 0 -leff 1 -tox 2. The use of option -multi is as follows – If there is a need to experiment such that all the tranistors in the circuit suffer the same process variations, then we can set -multi to 0 else its value must be 1.

A copy of the original netlist is modified by replacing NMOS_VTL by NMOS_VTL_0, next occurence of NMOS_VTL as NMOS_VTL_0 and so on. Similarly replacing PMOS_VTL by PMOS_VTL_0, next occurence of PMOS_VTL as PMOS_VTL_0 and so on. Also, if the instance parameter K2 from the Systematic Variations effect (by using the netlist obtained from layout extraction using Well Proximity effects) is present in the netlist, then its value is stored to be used while generating the PTM models and K2 and its value is removed from the netlist. It creates a hspice.include file which is included in the hspice netlist and points to transistor models (depending on the number of transistors in the netlist) going to be used in simulations.

The parameter values from the DOE file is used to generate transistor models. In this case, 4 transistors models are generated and a hspice simulation is done. The another set of 4 transistors models are generated and a hspice simulation is done. This is repeated N number of times depending on the DOE. For each of the simulation, the response is got from the .mt0 files and updated in the output DOE file

The ResDOEINVX1.txt is the resultant file with responses appended. This file needs to be opened from spreadsheet window by File->Load.

Once this file is loaded, click on the “RSM…” from the spreadsheet and the below window opens. Delay, which is the response can selected and moved from Factors to Responses as shown.

Also delete the control factor “SubWafer”. This factor is present by default and if not removed, the models cannot be fitted properly

The overall strategy for RSM is shown below. (Ref: Taurus Modeling Environment Taurus Workbench User Guide Version X-2005.10, October 2005, Fig 8.4, Page 8-11

The statistics of the factors and responses can be seen under the statistics tab.

Orders for the models can bet set in the orders tab. You can choose the model type and assing all the factors the same order or assign the order individually. X-order refers to interaction order between factors.

Then click on the “Fit Models”

The model will be fitted and added under the “Polynomial Models”. Select a model and click on the “Open” tab.

The following window opens and the measure of fit for the model can be studied.

Taurus Workbench uses four statistics to measure the quality of an RSM model:

• Residual RMS (Residual Root Mean Square Error)
• R2 (multiple coefficient of determination or R-Square)
• R2*(adjusted multiple coefficient of determination or adjusted )
• R2 press (predictive residual sum of squares)
The better the model fits the data, the smaller the RRMS value becomes and R2,R2* and R2 press become closer to 1.
Ideally, RRMS=0, R2 ,R2*, and R2 press =1.

If the measures are not good, then we can increase the order, interaction order and build new models. Then the best model can be selected by clicking on “Find Best Model”. The Best Model will be added under the “Polynomial Models”.

Once the best model is found out, choose that model and again click on the “Open” tab. In the “Polynomial Model” window, under the “Polynom” tab, the model equation for the response in terms of the factors is present. This equation can be exported to a .txt file for use in Monte Carlo Flow by selecting Export->Formula and saving it as a .txt file.

Delete all the models which are not required.Choose the best model and open the Perfomance Analysis Tool.

Increase the number of samples to say 1000 and click on “Sample Models”. We will be able to see a set of plots including the distributions/histograms of the response and the factors.