Technology File

The technology file tells Xic all it knows about the layers and display attributes, as well as being a general source of initialization information. The name of the file is ``xic_tech'', and an extension .xxx can be added to the name, so that if Xic is started with the -Txxx option, the technology file with the extension will be used. For example, ``xic -Ttrw'' would cause Xic to read xic_tech.trw.

It is legitimate to start Xic without reading a technology file, by using ``xic -T''. In this case, new layers will be assigned as needed as cells are read in. This can be useful for examining an undocumented GDSII file, for example. Once the layout has been read in, new colors and fill styles can be assigned, and the Save Tech command in the Attributes Menu used to dump an appropriate technology file for the next time.

The technology file is sought first in the current directory (where Xic was started). If the environment variable XIC_TECH_DIR is set to a directory path, that directory is searched. If a subdirectory of the current directory named ``techfiles'' exists, it is searched next. Finally, the technology file is searched for along the library search path. The library path can be set with the environment variable XIC_LIB_PATH. The default path is

( . /usr/local/xictools/xic/startup ).

The first matching terchnology file found in the search will be used. The default technology file has been provided by your system administrator. A personalized version can be generated with the Save Tech command.

The technology file generally begins with comment lines explaining the process that the file supports. The order of the sections that follow is rather flexible, though the printer driver blocks should appear last. It is recommended that one follow the ordering described here, which is the order used by Xic when generating a technology file, to be on the safe side. None of the sections is required to exist. Technology files for XicII and Xiv feature sets are simplified, omitting the sections that apply to unavailable features.

At the top of the file are macro definitions using the Set or Define keywords, and !set lines for setting global variables. The introductory part of the file further consists of optional path specifications. The layer blocks follow, which is where the core information about the particular technology resides. The electrical layers are defined first, followed by user-defined design rules, followed by the physical layer definitions.

The physical layers are followed by the standard via definitions, then the device blocks, where physical characteristics for device extraction are given. These are followed by script function definitions. Finally, there is a section containing display attribute specifiers and other parameters, and the hard-copy driver parameter blocks.

Long lines can be continued in the technology file by using backslash continuation. For example, the following would be read as one line:

This a line to be continued, the backslash \
must be the last character in the line.

The technology file has a macro facility which can be used to simplify the constructs and to customize the file to a particular variation of the technology.

The technology file may contain the following keyword/value pairs near the top of the file:

Technology name
The name can be any character token (no white space allowed) and defines a value for the predefined TECHNOLOGY macro. Additionally, the value of name is itself defined as a macro. These are not directly used by Xic, but the macro is placed in the name space of the macro preprocessor used when reading various types of input files, including the device library. The name is displayed in the status line of the main window, and is part of the information available for output in scripts and elsewhere.

Vendor name
The name can be any character token (no white space allowed) and defines a value for the predefined VENDOR macro. This is not directly used by Xic, but the macro is placed in the name space of the macro preprocessor used when reading various types of input files.

Process name
The name can be any character token (no white space allowed) and defines a value for the predefined PROCESS macro. This is not directly used by Xic, but the macro is placed in the name space of the macro preprocessor used when reading various types of input files.

DeviceLibrary libname
The libname is the name of a device library file which provides device outlines for use in schematics. If not given, the name defaults to ``device.lib''. The libname should be a file name, without any directory path. A file by that name should be found in the library search path on program startup.

ModelLibrary libname
The libname is the name of a model library file which provides SPICE models for use in SPICE output. If not given, the name defaults to ``model.lib''. A file by that name should be found in the library search path on program startup.

ModelSubdir dirname
The dirname is the name of a subdirectory of the directories of the library search path, in which are found SPICE model files. All directories of this name found in the library path will be searched for SPICE models. If not given, the name defaults to ``models''.

ReadDRF filename
This is part of the Cadence^TM compatibility package (see 5.7). The filename is the name of or path to a file in the format of a Virtuoso display resource file (including those from the Ciranova PyCell Studio). The full path should be given unless the file is in the library search path. This provides display attributes for layers.

ReadCdsTech filename
This is part of the Cadence^TM compatibility package (see 5.7). The filename is the name of or path to a file in the format of a Virtuoso ASCII technology file. The full path should be given unless the file is in the library search path. This provides layer and purpose definitions, rules, constraints, and other technology data. Layers defined in this file will appear in addition to those defined elsewhere.

ReadOaTech library
This will obtain Virtuoso technology information directly from OpenAccess. The library is an OpenAccess library, listed in the lib.defs or cds.lib file. This obtains technology information by use of the OpenAccess plug-in. There should be no reason to use both this and ReadCdsTech, as they should retrieve the same information.

ReadCdsLmap filename
This is part of the Cadence^TM compatibility package (see 5.7). The filename is a path to a Virtuoso layer-mapping file, which provides GDSII layer/datatype numbers for the layers. This can be used in addition to, and must be called after, ReadCdsTech. It is used to import the Stream mapping for the layers.

ReadCniTech filename
The filename is the name of or path to a file in the format of a Ciranova (now Synopsys) ASCII technology file. The full path should be given unless the file is in the library search path. This file format is superficially similar to a Virtuoso ASCII technology file, yet sufficiently different that a separate reader is required. The format is documented in the PyCell Studio distribution from Synopsys, and example files are provided (see 5.6).

When setting up a technology file for the PyCell Studio or something similar using Ciranova technology, it may be necessary to use this keyword more than once, if the technology is described in more than one file. It is also necessary to use the ReadDRF keyword to read display resource files.

For example, here is a skeletal technology file for the Ciranova 130nm model process in the PyCell Studio, which is installed under /usr/local/ciranova.

Set cni130 = /usr/local/ciranova/tech/cni130
ReadDRF $(cni130)/santanaDisplay/SantanaDisplay.drf
ReadCniTech $(cni130)/santanaTech/Santana.tech
ReadCniTech $(cni130)/santanaDisplay/SantanaDisplay.tech

The ability to read the Lisp/Skill file format used by Virtuoso is provided by an internal Lisp parser. The parser is available to run general scripts through the !lisp command, though this has limited utility at present.

In the technology file, is is sometimes useful to enable debugging output from the Lisp parser. The following keyword enables this.

LispLogging [y/n]
If this boolean keyword is set in the technology file, a log file will be generated when the Lisp parser is used. This can be used to track down issues when parsing Virtuoso-style input files. Asserting this keyword is equivalent to setting the Lisp logging in the Logging Options panel from the Help Menu, which otherwise can't be done before the technology file is read on program startup.

The logging output is put into a file named filename-lisp.log in the logfiles directory. The filename is the name of the input file being parsed.