next up previous contents index
Next: Generating ASCII Output from Up: The Convert Menu: Data Previous: Empty Cell Filtering   Contents   Index


The Format Conversion Button: Format Conversion Panel

The Format Conversion button in the Convert Menu brings up the Format Conversion panel, which is a front end to a number of direct conversion functions which translate an input file into output of another (or the same) format. These are direct conversions, i.e., the data are converted directly and do not enter the main Xic database. This means that there are relaxed memory limitations, so almost arbitrarily large files can be translated. It is also possible to perform scaling, data windowing or clipping, and hierarchy flattening while translating.

Conversions can also be performed by reading in a hierarchy and using the explicit output conversion in the Export Control panel.

A drop-down menu at the top of the panel selects one of four types of input:

Layout File
The source file is a normal layout file in one of the supported archive formats. The various input file formats are recognized automatically.

Cell Hierarchy Digest Name
Input will be read through a Cell Hierarchy Digest, as listed in the Cell Hierarchy Digests panel.

Cell Hierarchy Digest File
Input will be read through a Cell Hierarchy Digest found in a file on disk, as was generated from the Save button in the Cell Hierarchy Digests panel.

Native Cell Directory File
Input will consist of native cell files found in a given directory. All cells found in the directory that do not have a ``.bak'' file extension or duplicate a device library name, regardless of any hierarchical relationship or lack thereof, will be translated and concatenated into an archive file.

When translating CIF files, or from native cell files using Native Cell Directory, four-character CIF-style layer names found in the input must be mapped to layer and datatype numbers when output is in GDSII or OASIS format. If the layer exists in the layer table and the GDSII StreamOut parameter has been set, that mapping will be used. The StreamOut parameter is normally set in the technology file, but can also be set from the Tech Parameter Editor from the Edit Tech Params button in the Attributes Menu. When not mapped via an existing layer in the layer table, if the CIF layer name is a four-digit hex number, it will be interpreted as ``LLDD'' to obtain the GDSII layer and datatype numbers. If not in this form, a new layer number and datatype will be internally generated, using the UnknownGdsLayerBase and UnknownGdsDatatype variables.

When using Native Cell Directory, the directory can contain an alias file (see 14.3) that can be used to map native cell names to new names in the output. This file must be named ``aliases.alias'', and is never generated by Xic. It must be prepared by hand or some other means if needed. Each line contains the native cell name followed by the name to use in output, separated by white space. The Read Alias check box in the Format Conversion panel, or (equivalently) the InUseAlias variable must be set in order for the alias file to have effect.

The output format is selected through the tabs arrayed below the Input Source buttons. Each tab, when selected, displays a page that may contain format-specific settings. These pages are very similar to corresponding pages in the Export Control panel, and the settings in the two panels track. The Format Conversion panel provides some additional choices and options, however. The differences are described below.

GDSII
The output format is GDSII. When the Input Source is set to Layout File, this page contains an Input File Type menu. This menu contains two choices: archive and gds-text. The latter choice enables back-conversion to GDSII of the ASCII representation previously generated from a GDSII file using the ASCII Text output format tab. The archive menu choice should be selected when reading normal layout data.

The header of a GDSII file optionally contains information about fonts, reference libraries, and other things. This information is saved in a file named ``gds_header_props'' in the same directory as the output files, when converting to native files only. The file is subsequently ignored by Xic, as this information is not used by Xic.

OASIS
The output format is OASIS.

CIF
The output format is CIF.

CGX
The output format is CGX.

When translating to CGX format, the multi-box capability of BOX records in CGX is not used. However, this feature is used when CGX files are written from memory. Thus, reading a hierarchy into Xic and writing out a CGX file will probably result in a smaller CGX file than using the direct conversion.

XIC Cell Files
The output will be written to a family of native-format cell files.

When the selected output format is Xic Cell Files, the input will be converted to a number of native cell files, one for each cell defined in the input. The same result can be obtained by reading the input file into the database with the Open command, and then using the Export Control panel to generate the Xic files.

ASCII Text
The output will be converted to an ASCII text representation of the input file format, for GDSII, OASIS, and CGX input. This may be useful for debugging problematic layout files. The ASCII text format produced for GDSII can be back-converted to GDSII through use of the gds-text selection in the Input File Type menu of the GDSII page. The ASCII representation of OASIS files can be back-converted to OASIS with tools available from Anuvad. The two check boxes that appear on this page apply when translating OASIS:

OASIS text: print offsets
This sets/unsets the state of the OasPrintOffset variable, and when active the first token of each printed record contains the offset in the file or containing CBLOCK record. When not active, offsets are not printed.

OASIS text: no line wrap
This sets/unsets the state of the OasPrintNoWrap variable, suppressing line breaking when active. In this case, each record will use a single (possibly very long) line. When not set, lines are broken and indented.

Note that the Input Source choice will affect the availability of output format tabs, in particular if other than Layout File is selected, the available tabs are GDSII, OASIS, CIF, CGX.

The layer change module allows layer filtering and/or mapping to be applied during the conversion operation.

The Cell Name Mapping group of controls manages the cell name aliasing feature.

The windowing and flattening group can be used to set up area filtering or hierarchy flattening.

These may not all be available for every input/output format permutation. For example, the windowing operations are not available when the input format is Native Cell Directory.

If windowing, flattening, or empty cell filtering is set, only physical data are converted, i.e., there will be no electrical data in the resulting file.

When windowing is in use and not flattening, an area filtering operation is applied to subcells. For each subcell, a bounding box is obtained that contains all of the intersection areas of instances of the subcell that overlap the window area, in the space of the subcell master. If there is no such overlap area, the subcell will not appear in output. Otherwise, only objects within the subcell that overlap this bounding box will appear in output. If clipping is enabled, the overlapping objects will be clipped to the bounding box boundary.

Figure 14.1: Illustration of windowing applied over subcell instances.
\begin{figure}
\vspace{1.5ex}
\begin{center}
\epsfbox{write_region.eps}
\end{center}\end{figure}

In figure 14.1, the two instances of A together ``cover'' all the objects shown in A. All of these objects will therefor appear in A in output as shown, whether or not clipping is enabled. They appear outside of the window boundary, illustrating that the window boundary is not absolute, unless flattening and clipping are employed.

In the single instance of B, the object shown straddles the window area and will therefor be included in output. If clipping is enabled, the object within B will be clipped to the window boundary. The single instance of C overlaps the window area, so will be included in output. However, since none of its objects appear within the area, the C subcell will be empty in output. Empty cells will be removed from output if the empty cell filtering option is set. This will add some computational overhead, and in most cases empty cells are ``harmless''.

When the input source is a CHD or saved CHD file, when the user is prompted for the CHD name or file name, the user can supply an optional second argument. This is the name of a cell in the CHD (including any aliasing applied when the CHD was created) that will be used as the root cell in output. If no cell name is provided, the top-cell configured in the CHD will be used. If no cell is configured, all cells referenced in the CHD will be converted.

If the input file contains multiple top-level cells, and no windowing, flattening, or empty cell filtering is employed, files are simply streamed through the converter and all cells are translated, using the specified parameters. If windowing or similar is employed, a temporary Cell Hierarchy Digest (CHD) is transiently produced in memory, which is used to perform the conversion. In this case, only the ``default'' top level cell hierarchy will be converted. This is the first cell in the file that is not used as a subcell by another cell defined in the file. Of course, if the input format choice is a CHD, and the CHD is configured with a top-level cell, that cell will be used.

For input file types that support scaling, the conversion scale factor entry area will be active. A scale factor of .001 - 1000.0 can be entered in this area, and will be applied during the translation. When scaling, only the physical (not electrical) data are scaled.

The translation is initiated with the Convert button. The user will be prompted for the name of the input file (or directory for Native Cell Directory, and then the name of the output file, or directory for native files.

When generating an archive file and an error occurs. the archive file will normally be deleted. However, if the variable KeepBadArchive is set (with the !set command) the output file will be given a ``.BAD'' extension and retained. This file should be considered corrupt, but may be useful for diagnostics.



Subsections
next up previous contents index
Next: Generating ASCII Output from Up: The Convert Menu: Data Previous: Empty Cell Filtering   Contents   Index
Stephen R. Whiteley 2017-03-22