Layout Generation

ACT provides support to create new cells, as this may be necessary for certain asynchronous circuit families. This requires a complete layout configuration file that contains design rules.

Currently ACT does not produce fully routed cells. Instead, cell generation proceeds in two phases:

1. Layout for diffusion and polysilicon is generated with labels attached. This layout follows the design rules contained in the ACT layout configuration file. The layout is generated using .rect file syntax (shown below).
   • The .rect file can be easily converted to scripts for your preferred layout editor. An example where a Tcl script for the magic VLSI layout editor can be generated from a .rect file is distributed with the layout repository (part of the actflow distribution), and is called mag.pl.
   • The layout editor is used to complete the layout of the cell.
   • A new .rect file is generated from the layout editor that includes all the changes made (metal layers, etc.) when the cell was drawn. A sample script that does this for the magic VLSI layout editor that is part of the layout repository is mag2rect.py.
2. When .rect files (that correspond to the finished cells) for a cell is available in the cell rect search path, ACT will read them in instead of generating the unrouted cells.

ACT also generates the LEF for each cell along with the technology LEF. When the unrouted cells are used, ACT uses dummy pin locations for this purpose. Once the cell is routed (step 2), the generated LEFs will includes pin information, obstacles, etc. that is suitable for use in the rest of the place and route flow.

Preliminary layout files for cells required for place and route are generated in the .rect file format. As the name suggests, this file contains a list of rectangles. The purpose of this format is to be layout editor neutral; it is very easy to translate this file into commands to draw the cell in a layout editor.

An example .rect file is shown below:

bbox 0 0 24 72
rect in[0] polysilicon 15 2 16 5
rect in[0] polysilicon 13 6 15 8
rect out ndiffusion 19 24 20 27
rect # polysilicon 13 65 15 67
rect in[0] polysilicon 13 28 15 35
outrect out m1 19 24 21 27
outrect out m1 18 28 21 30
inrect in[0] m2 11 1 16 2
inrect in[0] m2 15 2 16 5
...

The file begins with the bounding box (bbox) directive. The four numbers are integer coordinates (in units of the layout scale factor), and the four-tuple corresponds to the lower left x-coordinate, lower left y-coordinate, upper right x-coordinate, and upper right y-coordinate. The rest of the file contains rectangle definitions.

An inrect is a rectangle corresponding to an input pin, and an outrect corresponds to an output pin, while a rect is just paint to be drawn. Note that inrect and outrect are optional; they could also be simply specified as rect directives, but are useful as hints in terms of specifying which pins correspond to inputs v/s outputs.

A rectangle specifier (rect, inrect, or outrect) has an optional signal name (# means that there is no label directly attached to the rectangle), followed by the drawing layer name (from layout.conf), and followed by the coordinates for the rectangle. Even if a rectangle does not have a label, it may be electrically connected to another rectangle that has a label. If two rectangles are connected to each other electrically and have different labels, this is reported as an error.

A rectangle can be followed by an optional string that is left, center, or right. This is simply a hint that says this diffusion region has a transistor to the left only, to the right only, or on both sides. (A cell is drawn with vertical polysilicon.)

The coordinate system used by rectangles in this file are designed to work directly with magic's box command. In the magic layout editor, a box specified by

:box 0 0 10 20

is of size 10 by 20 units. If we view a box as a collection of 1 by 1 pixels, then this box occupies pixels starting from (0,0) to (9,19). All rects must be non-overlapping on their respective layers. Note that transistors, diffusion, and poly are all viewed as the same layer.

This bounding box corresponds to the place and route boundary for the cell. Note that this is for convenience only; this box is automatically re-computed by the ACT layout library based on the geometry of the cell. The .rect file reader used by the ACT layout flow ignores this line.

A user-specified place and route boundary and bounding box can be specified using the sbox directive. This has the same syntax as bbox, except it is used to override the bounding box computation within the ACT library.

The layout library has support for manipulating layout. To aid in this, a .rect file can include information about how one cell can be abutted with another during procedural layout generation. A special layer name called $align is reserved for this purpose.

rect # $align 2 2 8 8

This means that the box used for abutting this cell with another has the specified coordinates.

rect $l:name1 $align 2 2 2 2

This means that a left edge alignment marker called name1 is located at the specified coordintes.

rect $r:name2 $align 2 8 2 8

This means that a right edge alignment marker called name2 is located at the specified coordinates.

Similarly, $t: and $b: prefixes are used for top and bottom alignment markers.