next up previous contents index
Next: Native Cell File Format Up: Design Data File Formats Previous: The CIF File Format   Contents   Index


CIF Format Extensions

There have been numerous extensions to the CIF syntax used to enhance the capabilities of the original format. Some of these extensions have been accepted widely and have become essentially part of the standard. Xic uses these extensions, plus some further extensions, in native format files and in files converted to CIF without the Strip For Export button active. These extensions to the basic CIF syntax are enumerated below. Unless stated otherwise, the extension is applied identically in native cell files and CIF output.

When writing a cell hierarchy in CIF format, when the top-level cell is known, the writer will add a transform-less symbol call of the top-level symbol just before the final End line. Thus, the two final lines look like

C top_cell_number;
End
MOSIS specifically requires this. If the top level cell is unknown, which is true when translating directly from another format, this is skipped. Xic does not require or use this line.

  1. Layer names can be arbitrarily long in CIF files generated or read by Xic, there is no four-character limit as in traditional CIF. In order to produce traditional CIF output, layer names should follow the traditional CIF limitation. Unlike some extensions, there is no provision for enforcing traditional CIF output, when layer names are arbitrary. Prior to release 3.3.0, Xic used CIF-style layer names.

  2. If a semicolon is preceded by a backslash character, the reader will strip the backslash and propagate the semicolon as an ordinary character, and not as a record terminator. Thus, label and property strings may contain semicolons if they are ``hidden'' with a backslash.

  3. Comment, label, and property strings can be arbitrarily long. Other interpreters, and older releases of Xic, may limit these lengths. Beware that the GDSII and CGX file formats have a 64KB record size limit and cannot accommodate strings that would overrun this limit (see the GdsTruncateLongStrings variable).

  4. The DS (define symbol) line is always followed by a cell name extension line of the form
    9 symbol_name;
    This extension is widely used, and is a standard means for including the symbol names within the CIF framework.

    In native cell files, however, the DS line is preceded by the symbol name line.

  5. In Xic releases prior to 3.0.0, the symbol number part of an instance call was set to 0, i.e., the call sequence was always
    C 0 ...;
    when cell name extensions were used. Since cell names were provided through the extensions, the cell numbering is unneeded. In current releases, the cell numbering is retained and will appear in the instance calls, in all CIF output.

  6. In CIF, the name of the cell being instantiated may precede the ``C ...'' (symbol call) line, using the same format as associated with the DS line, i.e.
    9 master_name;
    C N ...;
    This is redundant in CIF, since the master name can be obtained from the symbol number. It is required in native cell files, as there is no symbol numbering.

    In native cell files only, instead of a cell name, the string can contain two words separated by white space. The first word is a path to an archive file (CIF, GDSII, etc.), library, or the name of an OpenAccess library. The second token would be the cell or library reference name. If the first word is a path to an archive file, the cell name is optional if the file contains only one top-level cell, this cell would be understood. When the cell is read into Xic, the master and its hierarchy will be read from the specified source.

    For example:

    9 /path/to/directory/containing/myfile.gds mycell;
    C 0 ...;

    If a native cell with instance calls in this form is saved as a native cell, the instance calls will retain this special form.

    Cell files that contain instance calls of this form can be produced in a couple of ways. One would first read the target archive cell into Xic, then create a new cell, and place one or more instances of the target cell. One can then write the new cell to disk as a native cell, and modify the instance calls with a text editor. Alternatively, one can use the rename function of the Cells Listing panel to change the name of the target cell to the two words as would appear in the instance call, i.e., for example the full path to the source file name followed by the cell name, separated by space. The rename will accept this form. Then write the current cell to a native cell file. There will be no need for text editing in this case. After doing this, however, you have a cell in memory with a bizarre name, best to clear the database or restart Xic.

  7. Labels are specified with a unique syntax:
    94 «label string» x y flags width height;
    This is a further extension of a widely-used extension for labels, which does not have the flags, width, or height fields and the delimiters around the label. The original extension also required that the string contain no white space.

    The width and height are the dimensions of the untransformed bounding box of the label. The label will be stretched to fill this area. The label is surrounded by « ». The x and y are the reference coordinates, which by default is the lower left corner of the bounding box. The flags entry specifies transformations applied to the label at the reference point, and other rendering information. See C.2 for more information.

  8. Cells and instances can be preceded by properties of the general form
    5 prop_num prop_string;
    The property number prop_num is an arbitrary integer. The property string begins with the first non-space character following the integer, and ends with the semicolon (the semicolon is not included). The string can contain any alphanumeric, punctuation or white space but not `;' for obvious reasons. There are a number of properties used by Xic, particularly in electrical mode. This extension is widely used.

Xic writes the electrical information in a second symbol definition which immediately follows the physical cell definition in native files, but after the terminating token of the physical cell. Similarly, when Xic writes a CIF file without the Strip For Export function active, the electrical CIF representation immediately follows the physical CIF data, after the termination token.

In Xic releases prior to 3.0.0, the cell terminator was the single character E. This was used in both native cell files and unstripped CIF. In the present release, the cell terminator is always ``End'' in CIF, ``E'' in native cell files..

Whether or not these extensions are used when writing CIF output is controlled by a set of flags, which can be individually set from the CIF page of the Export Control panel. Actually, there are two banks of these flags, one bank is used when Strip For Export is set, the other bank is used when Strip for Export is unset. In the case of Strip For Export set, the flags all default to 0, so no extensions are used. In the case of Strip For Export unset, the flags all default to 1, so all extensions are used.

The user can set these flags individually through the Extension Flags menu in the CIF page of the Export Control panel. The bank of flags being set is determined by the state of the Strip For Export button and variable.

The flags in the menu have the following effects.

scale extension
Traditional CIF has a fixed resolution of 100 units per micron. This extension will add a comment of the form
(RESOLUTION nnn);
near the top of the file, and use nnn as the file resolution. The CIF reader must check for this comment and scale numerical values accordingly.

Xic normally uses internal units in unstripped CIF and native files, signaled with the addition of a comment line ahead of the first symbol definition something like:

(RESOLUTION 1000);
Xic will look for this comment, and interpret the coordinates accordingly. If no comment is found, the CIF default of 100 units per micron is assumed. Xic will always use internal units when writing a CIF file when this extension is enabled, and 100 units otherwise.

cell properties
Properties may be applied to cell definitions, ahead of the DS.

inst name comment
Comments of form
(SymbolCall cellname);
are added ahead of instance `C' calls.

inst name extension
Text in the form
9 cellname;
is added ahead of instance `C' calls.

inst magn extension
Cell instance `C' calls can be preceded by a magnification extension of the form
1 Magnify magn;
where magn is a magnification factor. All internal structure of the cell will be scaled by the given factor, which is a floating point number greater than zero. This extension will appear in physical cell descriptions only. It is unique to Xic.

inst array extension
Cell instance `C' calls can be preceded by an array extension of the form
1 Array x dx ny dy;
where nx and ny are the number of cells to array in the x and y directions, and dx and dy are the spacing between cells. This extension was used in earlier CAD programs.

inst bound extension
Cell instance `C' calls can be preceded by a bounding box extension of the form
1 Bound left bottom right top;
The left, bottom, right, top are the coordinates of the parent cell defining the bounding box of the subcell. This extension is not currently used, though it is written into the files. It is unique to Xic.

inst properties
Properties may be added ahead ahead of instance `C' calls.

obj properties
Properties may be added ahead of B (boxes), P (polygons), and W (wires).

wire extension
The end style of wires is not part of traditional CIF. In this extension, text of the form
1 7033 PATHTYPE n;
may be added ahead of wires to specify an end style. The values of n are 0 (flush ends), 1 (rounded ends), or 2 (extended ends, the default).

This extension was used in Xic prior to 2.5.23. It has been superseded by wire extension new, which will have precedence if both extensions are enabled.

wire extension new
This overrides wire extension, wires include an end-style designation:
W0 | W1 | W2 width x-y data;
The end style of wires is not part of traditional CIF. In this extension, the wire end style 0-2 immediately follows the `W', with the rest of the line as in traditional CIF. The end style is the same as the GDSII path type: 0 for flush ends, 1 for rounded ends, and 2 for extended square ends.

This extension was introduced in release 2.5.23. Older releases of Xic are not compatible with this extension.

text extension
Label string text is enclosed in « », and may include white space. Without this extension, white space characters in the label text will be replaced with underscores. In both cases, semicolons are replaced with underscores. This extension applies with any of the label format choices.


next up previous contents index
Next: Native Cell File Format Up: Design Data File Formats Previous: The CIF File Format   Contents   Index
Stephen R. Whiteley 2024-09-29