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 internal 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.

The rect command is specifed by 2 coordinate pairs, following the above example:

rect <label> <layer> <x0> <y0> <x1> <y1>

rect # m1 0 0 10 20

This would occupy the pixels at coordinates (0,0) to (9,19).

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.

A alignment box is required to mark the boundary the next cell is abutted to:

rect # $align 2 2 8 8

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

The layout engine checks if it can abut 2 cells by looking up if they have a matching label, so next to the abutmentbox you need to specify abutment markers: these markers are just a single coordinate thus the first coordinate pair is just repeated.

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.

For $l:/$r: labels, the x-coordinate is taken from the lower left/upper right x-coordinate of the abutment bounding box. Similarly, for $b:/$t: labels, the y-coordinate is taken from the lower left/upper right y-coordinate of the abutment bounding box.

.rect files can also include subcells. A subcell is specified using cell rather than rect. The cell specification consists of three parts:

• The cell type and cell instance name. The cell type is used to determine the .rect file name that should be used to get the detailed geometry of the subcell. The file name used is typename.rect, in the same way that ACT cells are read/written to the .rect format. The instance name corresponds to the ACT instance name for the subcell.
• A transformation matrix, which is specified using the standard LEF notation for orientation and a shift amount in the x and y direction. The standard LEF orientation specifiers are N, S, E, W, and FN, FS, FE, FW.
• An optional array specifier, that includes the array size and pitch in the x and y dimension.

The following shows an example of a subcell without an array:

cell myproc p1 N 0 0

This is a subcell with myproc as the cell type, p1 as the instance name, no rotation/flipping (N), and no shift amount in x or y.

A version of this cell that is arrayed as a 2×3 array with x-stride of 10 and y-stride of 20 is

cell myproc p1 N 0 0 arr 2 10 3 20

The instance names would be p1[0][0], …, p1[1][2].

.rect files are designed to be easy to convert into other formats. We discuss some of the issues involved in converting these files into two popular formats: .mag, for the magic VLSI layout editor, and .gds, GDS files used by the foundry as well as other open-source tools like Klayout.

The magic VLSI layout editor uses abstract layer names to reduce the burden of manual layout. Examples of these abstract layer names are:

• pdiffusion, for p-type diffusion.
• ntransistor, for n-type transistors.

(Note that the actual layer names are defined in a magic technology file, and can be any name. The names used in the examples correspond to those from the original MOSIS scalable CMOS design rules.)

GDS layers directly correspond to the layers required by the foundry. For example, pdiffusion normally corresponds to the region that is the intersection of the generic diffusion layer and the layer that defines the p-type select. magic contains conversion rules that generate GDS layers from magic layers, and for simple scenarios this approach works. However, there are situations when this conversion can create design rule errors in the GDS. The typical workaround is to write a magic technology file that is conservative, so that the auto-conversion process works properly, although sometimes this is not possible.

The .rect files represent a hybrid approach. We use magic layer names, but also allow some raw GDS layers to be specified so as to correct any design rule errors that might result from automated conversion from the magic-style layer names to GDS. Concretely:

• We allow the user to specify all wells
• We allow the user to specify p-type select and n-type select
• We allow the user to specify p-plus select and n-plus select (for well contacts)
• While we may use contact names, the contact itself ONLY corresponds to the via—surrounding material must be explicitly drawn

Note that this approach was already used in magic for more advanced technology nodes and is just a matter of correctly setting up the magic technology file.

The key to correct conversion to/from magic technology files is that the layers in the layout configuration options match the magic technology file layers.

Labels in .rect files can include square brackets, which are illegal characters for magic label names. We translate those to parentheses (which will never appear as valid identifier names in Act).

Converting .rect files to a script to draw layout for magic is straightforward, and the ACT tools come with a script mag.pl that creates commands for magic that can be sourced to draw the layout from the .rect file. Converting .mag files to .rect is a bit trickier because labels are stored in a separate section of the .mag file, whereas .rect files associate a label with a tile. Normally one reads in the entire .mag file, and then associates labels with the appropriate rectangle before emitting the .rect file. A sample script for this purpose is also provided and is called mag2rect.py.