Any of these file types can be read by Xic (Xic automatically determines the file type) or be converted, perhaps with windowing, scaling, or flattening, to another of the file types. Data input in a given format will remain in that format when written, unless explicitly converted. Xic also has the unique ability to generate its own technology database on-the-fly while reading any format input file. Any GDSII file (for example) can therefore be read into Xic without prior knowledge about what the file contains.

Xic includes a powerful C-like native scripting language for implementing user-defined commands and parameterized cells. Xic allows users to write custom commands which appear as buttons in the "User" menu. These commands can utilize a rich library of primitives for controlling the operation of Xic, producing geometrical manipulations or providing analysis, and other operations. A debugging window is provided that allows single stepping through scripts, breakpoint setting, editing, and other functions.

Scripting can also use the popular Python and Tcl/Tk languages. Most of the library functions are exported through wrappers and are thus available in these languages. Synopsys/Ciranova Python-based portable PCells ("PyCells") are supported, with the stretch handle and auto-abutment protocols implemented internally and thus usable from any of the supported languages.

Native language scripts are just-in-time compiled, and a function is compiled only once while it remains in memory, so that execution is highly efficient. Graphics can be exported to foreign X-windows, thus it is possible to create custom graphical interfaces to Xic using Tk or Python.

One popular use of the user scripting capability is to create simple, menu-based commands or parameterized cells for creating certain geometrical objects, which are often needed in high frequency circuit design. However, the user's imagination will almost certainly lead to other uses of this extremely flexible facility, to provide time saving automation of the user's specific design tasks.

Attention OEMs! Xic is unique in having a facility for exporting design manipulation and rendering capability as a "back end" for a custom design automation system. A unique "server mode" allows Xic to operate as a 'daemon', performing remote number-crunching geometrical tasks in support of the user's custom front-end. The Scripting Interface Xic includes a built-in script compiler and extensive script function library. Server Mode Xic can operate as a server, or "daemon". While in this mode, Xic communicates through a BSD socket, and normal graphics and console output are suppressed. Commands, in the form of native script language statements and functions, are sent to Xic via the socket. Graphics can be exported to a Tk or other X-window. Batch Mode Xic can perform batch-mode processing of design data. As in server mode, normal graphics and console output are suppressed, though graphics can be exported. Operation is controlled by a script, and the process terminates when the script completes, unlike server mode where the process remains active. With powerful and highly efficient geometric manipulation and measurement, layer synthesis, hierarchy management and format conversion capabilities, not to mention DRC, extraction, and a host of other capabilities, Xic may well be the engine for the custom tool you envision. Use of Xic instead of developing custom software is a no-brainer. Whiteley Research will work with you. If you need a special feature or hook, and the request is reasonable, you'll get it. Much of the existing interface has been developed in response to customer requests.

Hard copy support is available for a variety of printers and file formats, including Postscript (mono and color), HP laser, and HPGL. Export to all popular image formats is available.

In physical mode, design rule checking can be performed as each new object is created or modified. The user is given complete control over the design rules, which can be edited, disabled, or rules added interactively. The user can initiate batch mode design rule checking over a given area or over a complete cell in the foreground or background. Design rule checking is performed over a pseudo-flat internal representation of the layout, so that physical rules are checked without any constraint based on which subcells contain the geometry.

Xic has an extraction menu which allows netlist and parameter extraction from physical data, and layout vs. schematic (LVS) checking to ensure error-free designs. A unique "paths" command highlights all objects electrically connected to a selected conducting object. Internal algorithms provide extraction of resistance, capacitance, inductance, and transmission line parameters (assuming microstripline geometry), and extraction of arbitrary device types as defined in the technology file. Xic can build or update a working schematic from a physical layout or a SPICE file. Xic contains an interface to the FasterCap program from FastFieldSolvers.com for three-dimensional capacitance extraction, as well as to the open-source FastCap and FastHenry programs, the latter for three-dimensional inductance extraction.

Default SPICE interface support is provided for a wide variety of devices, even Josephson junctions. Additional devices and subcircuits can easily be added by the user, or changes can be made to existing devices, by editing a single text file. Xic also provides a high-powered model library search engine compatible with any SPICE format model or subcircuit library files, such as those provided by semiconductor manufacturers.

When the WRspice simulator is available, Xic works seamlessly with WRspice, giving the illusion of a single application. Simulation can be initiated, controlled, and results plotted through Xic. The WRspice binary need not be local, one only needs connectivity to a machine with a licensed copy of WRspice.

Below are some of the interesting new features, as clipped from the release notes at the time the feature was added. Xic continues to evolve in response to customer requests and new technology development.

Server Mode

Xic now supports a "server mode" where Xic can serve as a "back end" for the user's or a third party application, performing the database manipulation tasks. In this mode, Xic can even export graphical rendering capability to an arbitrary X window.

Parameterized Cells

Xic now supports parameterized cells (PCells). These cells contain a script which is executed, with a given parameter set, when the cell is instantiated, providing differing geometry based on the parameters. Parameterized cells can be used to implement devices, contacts, and vias, often replacing dozens or hundreds of fixed-geometry cells, thus streamlining layout and reducing errors.

Executable Labels

Xic now supports executable labels. Clicking on this type of label will execute a script.

Native Library Files

Xic supports a new library file type which can provide multiple levels of indirection to symbol files. The symbols can be extracted from GDSII, CGX, OASIS, or CIF archives.

Object Polymorphism

Xic now supports modification of object geometry by setting properties.

Remote Data Access

Xic can now open design files on remote systems through FTP or HTTP protocol transfers. The Xic/WRspice help system now accepts general URL's, so that help windows can view web pages from the internet. You can even use this to download updates from this web site.

Installation

Xic Generation 3 has built-in capability for automatically checking for update availability, and for actually downloading and installing updates. After installing for the first time, the !passwd command should be run to enable these features.

Modularity

The code base was extensively reorganized, and subsystems have been modularized. Now, the programs are linked only with the needed modules. Previously, all functionality was linked, but unused features were disabled.

Separation of Electrical/Physical Data

The method by which electrical and physical data are associated has changed. In previous releases, symbol names were saved in a single hash table. The hash element contained cell definitions for the physical and electrical cells, which can be empty. The problem with this approach is that if there is no electrical data, which is true in many environments and is always true in XicII, the empty electrical cell definitions waste memory.

In Generation 3, electrical and physical cells have separate hash tables, so there is no longer storage required for empty cell stubs. This uses less memory when working (for example) with physical data only.

On-Screen Rendering

In Generation 3, all graphical layout displays are composed in local memory, which is then sent as a block to the graphics system. Previously, the graphics system (X windows) performed the rendering. The new approach can be hugely faster, particularly when running remotely over a relatively slow connection.

Digests

In older releases, use was made internally of an "archive context" data structure, that is a compact representation of a cell hierarchy with offsets into a layout file. This structure allows efficient access to the cells within the layout file, and provides the ability to work with files that are too large to reside in memory.

In Generation 3, this structure is called a "Cell Hierarchy Digest" (CHD) and given a more accessible and prominent position in the program interface.

New in Generation 3 is a companion data structure called a "Cell Geometry Digest" (CGD). This is a hash table that, for a cell name and layer, provides a highly compressed byte string that represents cell geometry.

A CGD can be linked to a CHD, in which case file reading operations through the CHD will retrieve geometrical data from the CGD instead of from the original layout file. Since both the CHD and CGD are in memory, this should be much faster than reading the layout file on disk.

There are new pop-ups which provide access to the saved CHDs and CGDs, and initiate various operations. One operation of interest is the ability to display a layout through a CHD. In this case, only the CHD resides in memory, allowing viewing of files that are far too large to be viewed in the normal way.

Another new feature is the "cell override table" which, when a file is accessed through a CHD, certain cells will be overridden by cells in memory. This allows editing of files that are too huge to fit in memory.

Xic can be used as a "geometry server" to provide access to cell geometry on a per-cell/per-layer basis to other hosts on a network.

File Merging and Assembly

A new "reference cell" feature allows a cell to act as a pointer to a file hierarchy stored in a file on disk. Reference cells can be placed in a layout in the normal way. When the layout is saved to an archive file, the reference cell is replaced with the actual cell hierarchy extracted from the referenced layout file, streamed into the new file. This can be used to create layout files containing much more data than can fit into memory.

A similar capability is provided by the Layout File Merge Tool, which is a panel which provides a graphical front-end to the !assemble command. This provides a means for merging cell hierarchies from multiple layout files into a single file, allowing transformations, windowing, etc.

Layer Table and Layer Palette

The previous method of displaying layers, using up/down buttons to advance to a new line of layers, was cumbersome at best for layouts with many layers.

In Generation 3, the up/down buttons are gone, and instead a scrollbar is provided. The scrollbar enables scrolling through all of the layers in use, which is far easier that clicking the buttons.

To make available a subset of layers in which the user has particular interest, a Layer Palette pop-up is available. The top part of the pop-up displays information about the layer under the mouse pointer. Below this info area are two rows that may contain layer icons, as in the layer table. The first row shows the last few "current layer" selections. The second row contains a "sticky" area, where layers can be dragged from the layer table and dropped. Clicking on any of these layers has the same effect as a similar click in the layer table.

Enhanced Library Support, Immutable Cells

The library support, whereby cells can be opened via indirection through library files, has been enhanced. Cells opened through the library mechanism by default have the new IMMUTABLE and LIBRARY flags set. The IMMUTABLE flag means that the cell is read-only. The LIBRARY flag means that the cell won't be included when writing a layout file. The user can set/unset these flags, and thereby has great control over which cells are written to output.

Limited Virtuoso Compatibility

For example, read in the Cadence drf and technology files directly, it may be no longer necessary to create a native technology file.

OpenAccess input/output

Hook directly to a Cadence OpenAccess database, or your own.

Support for Python PCells, and Much, Much More...

Click HERE to read the changes document.