In this mode, which applies to archive files, no geometry is saved while the file is opened, only the cell hierarchy is saved in memory. However, when geometry is needed, it will be read directly from the archive file. This feature is to accommodate huge files which would require more than the available memory or produce excessive page swapping when read in the usual way. The feature is probably most useful in server mode, or in scripts where only a small part of the design needs to be in memory at one time. It is suitable for analysis operations, but typically not for synthesis, as changes made are inherently volatile.
Warning: do not use gzipped (.gz) files in skeleton mode. Although these will ``work'', performance will be poor due to the need to decompress for each file access.
Skeleton mode is established by setting the boolean variable SkeletonMode with the !set command or equivalent. While this variable is set, archive files will be read in the manner described, other files will be read normally. Any number of skeletal hierarchies can exist in memory simultaneously (earlier versions allowed only one).
The only purpose of the SkeletonMode variable is to provide a means to read files skeletally using the normal input functions. The variable is ignored in operations once the hierarchy is in memory.
A second way by which skeletal hierarchies can be read into memory is through use of an archive context and the CxSetupSkeleton function. This can be more conservative of memory.
When the current cell is skeletal, functions such as SkelReadGeom can be applied. The skeletal status flag is kept in the cell, and can be displayed with the Info command.
In skeleton mode, only physical data are read. Unlike normal files, the electrical data structure is not created, saving memory space. Thus, none of the functions that require electrical data will work with skeletal cells.
To use skeleton mode, it is necessary to set a clipping window. The clipping window ensures that only the geometry that overlaps the clipping window with nonzero intersection area, when reflected into the coordinates of the top-level cell, will be read into memory. The clipping window is set with the following script function:
SkelSetDataWin(l, b, r, t)The arguments are the left, bottom, right, top coordinates, in microns, relative to the origin of the current cell. If scaling has been applied when reading the skeleton, the arguments must be the scaled coordinates. This and all script functions can be executed directly from the prompt area by preceding the function call with ``!!'' (two exclamation points).
Geometry is actually read into memory with the following script function:
SkelReadGeom(depth)The depth specifies the depth into the hierarchy to read. This can be -1 to specify reading all of the hierarchy. Once this function has been called, all of the standard physical-mode operations can be performed on the cell data, in the regular way.
The geometry presently in memory can be cleared with the script function
SkelClearGeom()Since the database is cleared before reading in new data with SkelReadGeom, this function is not generally needed.
Although in general geometry is not kept persistently in memory, relaxing this can improve performance in some cases. This feature is enabled by the following variable:
SkelSaveNum (integer > = 0)If a cell contains this many geometrical objects or fewer, it is retained in memory. The assumption is that there are small cells that are instantiated in many places, and it is more efficient to cache these cells rather than having to update from the file each time the content is needed. This variable should be set to some small number. If set to 0, this feature is effectively disabled.
Finally, it is possible to write the windowed data directly to a new output file with the following function:
SkelWriteGeom(depth, filename, flat, clip)This function will write the cells and objects that have nonzero area overlap with the current skeleton window to a file. The type of file written is implied by the filename extension. The remaining arguments are flags that indicate hierarchy flattening and object clipping. See the function description for complete information.
The following sequence should appear in scripts to change the skeleton mode data window.
SkelSetDataWin()Virtually all of the time these two functions will be used together in the sequence shown. Following this sequence, all operations are available, though the hierarchy contains only the objects which reflect into the data window in the coordinate system of the top-level cell. Although objects can be added/edited in the normal manner, the changes will be lost when the file data are re-read. A disk file can be saved from skeleton mode, but be careful to not clobber the original file with a file with partial content. The original file will be saved with a ``.bak'' extension once.
SkelReadGeom()
These script functions have no effect on normal cells.
Once the hierarchy has been read and a clipping window set, the user can use any appropriate script functions or physical-only operations including DRC. Only the geometry whose bounding box overlaps the clipping window with nonzero area will ``exist''. The process of stepping through a huge design piece by piece in this way is expected to be much faster than the straightforward method, which may not even be possible due to memory limitation.