KLayout Documentation (Qt 4): Main Index » KLayout User Manual » Design Rule Check (DRC) » Design Rule Checks (DRC) Basics

Design Rule Checks (DRC) Basics

• Basic scripts
• Installing and running scripts
• DRC waiving flow
• Using KLayout as a standalone DRC engine

KLayout supports design rule checks beginning with version 0.23. The capabilities of the DRC feature include:

• Basic DRC checks such as checks for minimum width and space.
• Layer-generation methods such as boolean operations and sizing.
• Extended geometrical checks such as overlap, enclosure and inside and outside checks.
• Support for edge objects derived from polygons or as output from other functions. Edge objects are useful to implement edge-related operations, for example selective sizing.
• The capability the work with multiple input layouts.
• Support for text object layers. Text objects are convenient for tagging polygons or labelling nets.
• Cell filtering, local (region-constrained) operation.
• A tiling approach for large layouts which can be configured to make use of multiple CPU cores.
• A hierarchical option.

The DRC functionality is controlled by a DRC script. A DRC script is basically a piece of code which is executed in the context of the DRC engine. The script language is based on KLayout's integrated Ruby interpreter and wraps the underlying object model into a lean and expressive language. Script execution is immediate. That means, that it is possible to embed conditional statements or loops based on the result of a previous operation. It is also possible to code low-level operations on shapes inside the script, although this will be considerably slower than using the functions provided.

Output of the DRC script can be sent to a layout layer or a report database. The report database is visualized in the marker database browser.

Basic scripts

Runset writing is described in detail in DRC Runsets. Here is a simple example for a DRC script:

report("A simple script")

active = input(1, 0)
poly = input(6, 0)
gate = active & poly
gate.width(0.3).output("gate_width", "Gate width violations")

metal1 = input(17, 0)
metal1.width(0.7).output("m1_width", "M1 width violations")
metal1.space(0.4).output("m1_space", "M1 spacing violations")

This script will compute the gate poly shapes from the active and poly layers using a boolean "AND". The active layer has GDS layer 1, while the poly layer has GDS layer 6. On this computed gate layer, the script will perform a width check for 0.3 micrometer. In addition a width and space check is performed on the first metal layer, which is on GDS layer 17.

Let's take the script apart:

• report("A simple script")
  This line will instruct the script to send output to a report database. The report database is shown in the marker database browser. The description text of the report database is given in brackets.
• active = input(1, 0)
  This line will create an input layer. "Layers" are basically collections of shapes, edges or edge pairs (edge pairs are objects created as output of check methods). "input" is a function which delivers a layer object. Checks and other functions are performed on those layer objects in the spirit of object-oriented programming and the underlying Ruby interpreter. "active" will be a variable that holds such an object.
  The parameters of the "input" method specify where to take the input from, in that case GDS layer 1 and database 0. In that simple form, the first layout loaded into the current view is used for input.
• poly = input(6, 0)
  This line will create another input layer for poly silicon (from GDS layer 6, datatype 0).
• gate = active & poly
  This line will compute the boolean "AND" of active and poly layers. The "&" is the operator for the boolean "AND" operation which computes the intersection of active and poly. The result will be sent to a new layer and a new layer object is created and put into the "gate" variable. This layer object is a temporary one and will not appear in the output but can be used in subsequent operations.
• gate.width(0.3).output("gate_width", "Gate width violations")
  This line combines two operations into one statement: first is performs a width check against a minimum width of 0.3 micrometer using the width method on the "gate" layer. A "method" is a function performed on a specific object and the notation used in the DRC script is the ".". "gate.width(0.3)" will perform a width check on the gate layer and create a new layer object with "edge pairs" for each violation. "Edge pairs" are marker objects consisting of two edges or partial edges which describe where two edges violate the check condition. In the simple geometrical checks, there are always two edges involved in such a violation - hence such a violation is best described by a pair of edges.
  The result of the check is sent to a report database category using the "output" method. Again this is a method called on an object, in that case the edge pair collection returned by the width check. The parameters of the output method describe a formal name and a readable description of the category.
• metal1 = input(17, 0)
  As before, this statement will fetch input from GDS layer 17 and datatype 0 and create a layer object representing that input.
• metal1.width(0.7).output("m1_width", "M1 width violations")
  As for the gate, this statement will perform a width check (this time for 0.7 micrometer) and output the violation markers to a report database category.
• metal1.space(0.4).output("m1_space", "M1 spacing violations")
  And again a geometrical check: this time a space check for minimum space of 0.4 micrometer.

The script can be written in several alternative forms. Here for example is a very brief version of the gate width check:

(input(1, 0)*input(6, 0)).width(0.3).output("gate_width", "Gate width violations")

Some aliases are provided for the boolean operation, so if you prefer object-oriented notation, you can use the "and" method:

input(1, 0).and(input(6, 0)).width(0.3).output("gate_width", "Gate width violations")

or the functional notation:

and(input(1, 0), input(6, 0)).width(0.3).output("gate_width", "Gate width violations")

Dimensions can be given in different ways:

# floating-point (will default to micrometer)
gate.width(0.3).output("gate_width", "Gate width violations")

# floating-point with unit
gate.width(0.3.micron).output("gate_width", "Gate width violations")
gate.width(300.nm).output("gate_width", "Gate width violations")

# integer values will give dimensions in database units!
gate.width(300).output("gate_width", "Gate width violations")

# as variable
min_width = 300.nm
gate.width(min_width).output("gate_width", "Gate width violations")

Installing and running scripts

To create a DRC script, choose "Tools/DRC/New DRC Script". KLayout will open the Macro development IDE and create a new script. The first thing to do is to give the script a proper name. The cursor is already on the name - just enter a new name and press "Enter".

The next step is to give the DRC script some description. Press the "Properties" button in the macro editor's toolbar and enter a description text - this is the text that will appear in the menu entry.

The DRC script will now appear in "Tools/DRC" with the description and selecting that entry will run the script.

To edit the DRC script, choose "Edit DRC Scripts" from "Tools/DRC" or enter the macro editor IDE and select the DRC category (the tab above the macro list).

DRC scripts can be shared or installed globally like normal macros. They can be put into the "macros" folders, but the preferred way is to deploy them in a folder called "drc" beside the "macros" folder. KLayout will scan various places for DRC scripts or macros, including the installation path and the application folder (usually in the home directory). Both places can be used to store DRC scripts.

For the more experienced user, DRC scripts are basically just macros bound to a DRC interpreter instead of the plain Ruby interpreter. You can create and run DRC scripts like ordinary macros. Use "Macros/Macro Development" to enter the macro IDE and create a DRC scripts with the "add macro" function (the "+" button). Choose "DRC scripts" as the template to use (in the "General" section). DRC scripts are by default bound to the DRC menu, but that can be changed in the same way than for any ordinary macro.

See About Macro Development for more details about the macro development facility.

By default, DRC scripts are put into the DRC category of the macro IDE. Macro categories are a way to organize macros, but do not imply a certain runtime behavior. Hence, DRC scripts can be put into any other location beside the "drc" folders selected by the DRC category.

DRC scripts can be executed in the debugger like ordinary macros and breakpoints or single-stepping can be used to debug DRC scripts. Behind the scene, the DRC commands are mapped to Ruby functions, so stepping into such commands will reveal the code behind the DRC functions.

DRC scripts are stored in ".lydrc" files in KLayout's macro format. Those are XML files containing the script code in the text element. KLayout also recognizes plain text files with the extension ".drc", but those files are usually lacking the necessary meta-information that allow KLayout to bind them to a menu entry. Hence such files can only be run from the macro IDE.

DRC waiving flow

DRC waiving is a process of signing off DRC violations that cannot be avoided. Usually DRC waiving is not encouraged, as manufacturability of the device cannot be guaranteed if DRC violations are present. Even worse, giving a non-clean layout into manufacturing may create a contamination risk that manufacturers will try to avoid. Hence, non-DRC-clean layouts are usually rejected.

Still there are some legit reasons for DRC waiving. Sometimes DRC rules do not apply because a specific technology option is not used by the device and corresponding DRC rules do not apply. Or, a certain DRC rule may be a recommended rule, and violating it is not forbidden. In that case, a DRC violation can be waived at your own risk. Waiving is not a formal process. Usually, the manufacturer will ask for a confirmation if DRC violations are present. KLayout can help documenting violations and copying the waivers from one DRC run to the next.

The DRC waiving flow of KLayout is the following:

• In the initial step, a RDB database is created by the DRC run, using the "report" command with a destination file.
• This report is inspected in the marker browser. You can add comments, set flags and add screenshots. This is also the time to waive DRC violations that you deem necessary to be waived. The marker browser has a "waive" button which sets or resets the waived flag of the selected markers.
• When finished, save the edited database to a 'waiver DB' using the marker browser's 'Save As Waiver DB' feature from the File menu. Technically, this will write the report database to a second file. This second file is named like the original one, with a ".w" added to the file name.
• When you run the DRC again, KLayout will find this waiver DB file and apply attributes from the waiver DB to the current report database. These attributes include the flags, images and comments. This will - among the other annotations - apply the waived flag to the report database items.

In the waiving step, KLayout will apply attributes to items with the same value (i.e. shape), category and cell. This specifically means, that when you rename a cell, waivers will no longer be applied, or - in the worst case - be applied to the wrong cell. Hence, waiving should be done late in the process, when cell names are unlikely to change.

Using KLayout as a standalone DRC engine

KLayout can be used as a non-interactive DRC engine using a specific kind of DRC scripts. Since there is no "current layout" in standalong engine mode, those DRC scripts have to specify input explicitly using the "source" function. The same way, output has to be specified explicitly using either "target" to create an output layout or "report" to create an output report database (see DRC Reference: Global Functions for details about these functions).

Here is an example. It reads layer 1, datatype 0 from "input.gds", sizes it by 200 nanometers and writes the output to "out.gds", layer 10, datatype 0:

source("input.gds")
target("out.gds")
input(1, 0).sized(200.nm).output(10, 0)

Here is another example which saves the results to category "sized" of the report database file "out.lyrdb":

source("input.gds")
report("Output Database", "out.lyrdb")
input(1, 0).sized(200.nm).output("sized")

To run these DRC scripts, save the scripts to a file with suffix ".drc" and run it like shown below (replace "my.drc" by your file). It is recommended to disable some of the features not used in that case and put KLayout into non-interactive batch mode with "-b":

klayout -b -r my.drc

"-b" will disable all of the user interface functionality and puts KLayout in engine mode in which no display connection is required on Unix. Implicit loading of macros from the various search locations is disabled (you can still load some with "-rm") and the configuration file is neither read nor written, which causes less I/O and avoids write conflicts between different instances of KLayout.