Differences

This shows you the differences between two versions of the page.

--- tools:layout:rect [2025/09/21 11:53] – [Abutment and alignment] rajit
+++ tools:layout:rect [2025/09/25 17:57] (current) – [Hierarchy] rajit
@@ Line 78: / Line 78: @@
 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.
-===== Convertion to/from magic and gds layers =====
+===== Hierarchy =====
+''.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:
+<code act>
+cell myproc p1 N 0 0
+</code>
+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 2x3 array with x-stride of 10 and y-stride of 20 is
+<code act>
+cell myproc p1 N 0 0 arr 2 10 3 20
+</code>
+The instance names would be ''p1[0][0]'', ..., ''p1[1][2]''.
+====== Conversion to/from rect files ======
+''.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.
+===== Rect to/from magic =====
+The key to correct conversion to/from magic technology files is that the layers in the [[config:layout|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''.
+===== Rect to/from gds =====