There are four search paths used by Xic. Search paths are lists of directories, which are searched in left-to-right order for files of a particular type. In addition to search paths, Xic provides a ``redirect file'' mechanism for finding files, which supplements the search path. If a specific file is being sought, the first file with matching name is used. The format used for search path strings can be one of two forms:
( . )
( /usr/local/bin "/Program Files/xic/stuff" ~/work )
This format is the same in Windows and Unix releases, however in Windows, back and forward slashes are equivalent, and the drive specifier can appear in the entries.
In earlier Xic releases, parsing was fairly loose, and in particular hybrids of the two formats would be accepted. This is not true in the present release, due to support for white space in path entries. The format used in a path string must be consistent.
The following special symbols are recognized in entries:
|.||The current directory|
|..||The parent directory of the current directory|
|~||The user's home directory (Unix) or the content of the HOME environment variable (Windows)|
|~joe||The home directory of user joe (Unix only, no substitution in Windows)|
The four paths are the design data path, the library path, the help path, and the script path. The design data path is used to locate design data files, consisting of native cell, archive, and library files. The library path is used to locate the technology file, device and model libraries, and various other configuration files. The help path contains files for the help system, and the script path contains executable scripts and libraries which appear as commands in the User Menu.
These paths can be set in the technology file, the .xicinit or .xicstart initialization files, or by use of environment variables, or with the !set command. A specification in the .xicinit will override specification in the environment, which is in turn superseded by a specification in the technology file, and the .xicstart file supersedes the technology file. Once Xic is running, the !set command can be used to set or examine the search paths. Similar commands exist in the script interpreter interface function library.
In addition, the design data path is augmented with any path preceding a native cell file to open in the Open command. By default, the path is added to the beginning of the present design data path. For example, suppose a design hierarchy exists in the directory /usr/work. If the user enters /usr/work/maincell in response to the prompt which appears after pressing the Open button, then the file maincell is opened for editing, and the directory /usr/work is added to the front of the design data path. Once the design data path is updated, the cells in that path can be accessed by their base file name only. The treatment of any path which is given with a native cell to open in the Open command can be altered with the NoReadExclusive and AddToBack variables.
The use of paths facilitates user customization of Xic, particularly when the directories used in the system installation are not writable by the user. By installing a different search path, the user can augment or substitute for the system default files and libraries.
Below are the environment variable names and internal defaults:
|default:||( . )|
|default:||( . /usr/local/xictools/xic/startup )|
|default:||( /usr/local/xictools/xic/help )|
|default:||( /usr/local/xictools/xic/scripts )|
If the XT_PREFIX environment variable is set, its value will be taken instead of ``/usr/local'' in the defaults.
The ``variable'' field in the table above provides the name of the variable, which can be altered with the !set command to set the path. Unlike other variables, these are always defined and cannot be unset. The same name is also used as a keyword in the technology file.
Files containing cell data, whether Xic native, GDSII, or some other format, are expected to be found in a directory along the design data search path. The first file found matching the name requested is opened. Normally, it is desirable to include the current directory `.' in the design data path, otherwise files located in the current directory will not be found.
The technology file, device.lib file, model.lib file and other model files are found along the library path.
The search behavior of the library path is slightly different from the other paths, in that an attempt is made to open a file in the current directory before looking through the search directories. Thus, the current directory `.' is always logically at the head of the library path. There is no problem if `.' is also explicitly defined in the path. A consequence is that startup files that exist in the current directory will always have precedence over files located in other directories.
Each directory in the help path is expected to contain help database files. These files use names with an extension ``.hlp''. The directories may also contain graphics files used by the help system. Changing this path allows the user to provide their own help files for the custom functions (scripts) which appear in the User Menu, for example, or to add information topics, such as about local design rules, to the database.
The scripts and related files are found along the script path. Only files which have the extension ``.scr'' are taken as scripts. The directories in this path may also contain script menus, with extension ``.scm'', and files named ``library'' which contain subroutines used by other scripts. Whenever the script path is changed, a rehash is performed, i.e., the User Menu is rebuilt.