The ReadCdsTech keyword

This technology file keyword is used to import a Cadence Virtuoso ASCII technology file into Xic. The syntax is

ReadCdsTech techfile

The ASCII technology file is generally provided in process design kits intended for use with Virtuoso. The file name varies, but ``techfile'' and ``techfile.txt'' have been used. The file at minimum provides the list of layers used in the process. Generally, there is a wealth of technology information available, and the file can be quite large and complex.

If a display resource file is also being read, it should be read first. Other than this, ReadCdsTech can appear anywhere in the technology file, and will cause Xic to read information from the Cadence ASCII technology file given in techfile. This should be a full path to the file, unless the file is in the library search path.

The technology file is collections of ``nodes'', as understood by the Lisp parser. A named node has the form

name( data ... )

There can be no space between the node name and the opening parenthesis. The data are other Lisp nodes, strings, or numerical data or expressions. This can occupy arbitrarily many lines in the file. The file consists of successive Lisp nodes, with names and content that are defined by Cadence or OpenAccess. The nodes that are understood by Xic are described below.

Both Virtuoso 5.x and 6.x technology files can be read. Far more information can be obtained from 6.x (OpenAccess) technology files, however. This includes:

• Extraction technology keywords such as Conductor, Via, etc. (as are available from 5.x files) but additionally electrical/physical data such as Thickness, resistivity, and capacitance parameters are available.

• Design rules are generated from the ``constraint groups''.

This will provide a much more complete starting point from the technology file provided with a foundry kit. However, this still may be incomplete. For example, a typical technology file may provide thickness values for conductors only, not insulators.

Depending on the PDK, the imported design rules and derived layer definitions may require review and augmentation. The ``real'' design rules are likely provided in separate configuration files for Mentor Calibre, Cadence Assura, and/or others. In experience with one PDK, it was found that the rule set obtained through the OpenAccess technology database left a lot to be desired.

1. The very basic rules, such as MinWidth and MinSpace came through fine, including the spacing tables. Other simple rules also come through properly.

2. Derived layers come across fine, however within the syntax limitation, expresions are limited to a single operator, i.e., a form like ``layer operator layer''. Thus, a complex definition requires multiple derived layers for intermediate layers, which is acceptable. It was concerning, though, that the derived layers were not used anywhere within the technology file, such as in the constraints. There seemed also to be errors, for example one obvious place where ```and'' was used where ```or'' was clearly required.

3. The constraints helpfully included a design rule violation number, but were shown to be wrong when the rule was looked up. For example, One rule specified ``(PP OR NP) Enclosure of PO ...'', yet there were separate constraints ``PP Enclosure PO...'' and ``NP Enclosure PO...'' specified, which is wrong.

4. An attempt to DRC a known-clean layout with imported rules yielded a lot of bogus errors. Additional work would be necessary to obtain a ``good'' set of design rules.

5. As more tools use OpenAccess, perhaps there will be improvements in the rulesets provided through the OpenAccess technology database. At present, it appears that this is not primary to the serious DRC tools, but may be used by Virtuoso, possibly for editing feedback.

The tree below shows the hierarchy of the nodes that are recognized in the technology file. Most of these are ignored. Below we describe the nodes that are actually used, and what information they provide.

Below, nodes that were added for Virtuoso 6.1.4 are marked marked with an asterisk. The
constraintGroups listing is greatly simplified, there is actually far more structure than indicated.

    include
    comment
    controls
        techParams
        techPermissions
        viewTypeUnits *
        mfgGridResolution *
    layerDefinitions
        techLayers
        techPurposes
        techLayerPurposePriorities
            techDisplays
            techLayerproperties
            techDerivedLayers *
    layerRules
        functions *
        routingDirections *
        stampLabelLayers *
        currentDensityTables *
        viaLayers
        equivalentLayers
        streamLayers
    viaDefs *
        standardViaDefs *
        customViaDefs *
    constraintGroups *
        foundry *
            spacings *
                maxWidth
                minWidth
                minDiagonalWidth
                minSpacing
                minSameNetSpacing
                minDiagonalSpacing
                minArea
                minHoleArea
            viaStackLimits *
            spacingTables *
            orderedSpacings *
                minOverlap
                minEnclosure
                minExtension
                minOppExtension
            antennaModels *
            electrical *
        LEFDefaultRouteSpec *
            interconnect *
                maxRoutingDistance *
            routingGrids *
                verticalPitch *
                horizontalPitch *
                verticalOffset *
                horizontalOffset *
    devices
        tcCreateCDSDeviceClass
        multipartPathTemplates *
        extractMOS *
        extractRES *
        symContactDevice
        ruleContactDevice
        symEnhancementDevice
        symDepletionDevice
        symPinDevice
        symRectPinDevice
        tcCreateDeviceClass
        tcDeclareDevice
    viaSpecs *
    physicalRules
        orderedSpacingRules
        spacingRules
        mfgGridResolution
    electricalRules
        characterizationRules
        orderedCharacterizationRules
    leRules
        leLswLayers
    lxRules
        lxExtractLayers
        lxNoOverlapLayers
        lxMPPTemplates
    compactorRules
        compactorLayers
        symWires
        symRules
    lasRules
        lasLayers
        lasDevices
        lasWires
        lasProperties
    prRules
        prRoutingLayers
        prViaTypes
        prStackVias
        prMastersliceLayers
        prViaRules
        prGenViaRules
        prTurnViaRules
        prNonDefaultRules
        prRoutingPitch
        prRoutingOffset
        prOverlapLayer

We mention below only the nodes from which information is extracted. Note that this is a mixture of 5.x and 6.x nodes, providing unified support for all current Virtuoso releases. In most cases, a node with an unrecognized name will produce a warning message. These can be ignored, the purpose is only to identify ``new'' information in the technology file that might be useful to parse.

include
This node contains a string, which is a path to another Lisp file. That file will be opened and read.

controls/viewTypeUnits
For maskLayout, if microns, the Xic database resolutions 1000, 2000, 5000, 10000, and 20000 are accepted.

controls/mfgGridResolution
This will set the Xic MfgGrid parameter.

layerDefinitions/techLayers
This associates OpenAccess layer numbers with layer names and abbreviations. These are recorded in the Xic layer database.

layerDefinitions/techPurposes
This associates OpenAccess purpose numbers with purpose names and abbreviations. These are recorded in the Xic layer database.

layerDefinitions/techLayerPurposePriorities
This contains a list of layer-purpose pairs, using layer and purpose names previously defined. Each layer-purpose pair is used to create an Xic layer. These are created in the order listed.

In Virtuoso, there is no distinction between physical and electrical layers as there is in Xic. All Virtuoso layers are taken as physical layers, except for the following internal Virtuoso layer numbers which with any purpose number will generate an Xic layer listed in both the electrical and physical layer tables in Xic.

Layer Number	Virtuoso Layer Name
228	wire
229	pin
230	text
231	device
236	instance
237	annotate

layerDefinitions/techDisplays
This will assign the colors and fill patterns to layers that exist in the Xic layer table. This references the internal packet, color, and stipple lists created from the display resource nodes. In addition, the initial visibility and selectability states are set here, as well as the Invalid flag.

layerDefinitions/techLayerproperties
This node provides some directly applicable parameters, which are read and added to the appropriate layer. These include sheetResistance, areaCapacitance, edgeCapacitance, and thickness. The thickness value is specified in angstroms, which is converted to microns. The capacitance value units are picofarads and microns, thus no conversion is required.

layerDefinitions/techDerivedLayers
The derived layers will be imported directly, with the expression converted to an Xic layer expression string. The expression given in this node type consists of a single operator and two layer names. The operator keywords which map to geometrical combinations ('and, 'or, 'not, and 'xor) are accepted. Others are ignored.

layerRules/routingDirections
Layers found in this table are given the Routing attribute.

layerRules/viaLayers
The conducting layers are assigned the Conductor attribute. The via layer is assigned the Via attribute. This is in 5.x files only.

layerRules/streamLayers
A GDSII import/export mapping is applied for each layer given. This is in 5.x files only.

viaDefs/standardViaDefs
This identifies layers that are given the Via attribute. The metal layers that are referenced by the via are given the Conductor attribute. The standard via definition is imported, and will be available for via generation from the Via Creation panel from the Edit Menu.

constraintGroups/foundry/spacings/maxWidth
This identifies a MaxWidth rule.

constraintGroups/foundry/spacings/minWidth
This identifies a MinWidth rule.

constraintGroups/foundry/spacings/minDiagonalWidth
This will map to a Diagonal clause in a MinWidth rule.

constraintGroups/foundry/spacings/minSpacing
This maps to either a MinSpace rule (one layer given) or a MinSpaceTo rule if two layers are given.

constraintGroups/foundry/spacings/minSameNetSpacing
This provides the SameNet clause to a MinSpace or MinSpaceTo rule.

constraintGroups/foundry/spacings/minDiagonalSpacing
This provides the Diagonal clause to a MinSpace or MinSpaceTo rule.

constraintGroups/foundry/spacings/minArea
This identifies a MinArea rule.

constraintGroups/foundry/spacings/minHoleArea
This provides the dimension for area filtering in a NoHoles rule.

constraintGroups/foundry/spacings/minHoleWidth
This provides the dimension for minimum width filtering in a NoHoles rule.

constraintGroups/foundry/spacingTables
This provides tables of length, width, and spacing values, for size-dependent spacing rules. These tables are parsed and added to MinSpace and MinSpaceTo rules.

constraintGroups/foundry/orderedSpacings/minEnclosure
This maps to a MinSpaceFrom rule, with the source and target layers swapped. It provides the Enclosed clause, which applies when the target figure is completely surrounded by the source material. The alias minEnclosureDistance is also recognized.

constraintGroups/foundry/orderedSpacings/minExtension
This is almost identical with minEnclosure, but does not require that the target figure be fully surrounded. It maps to a MinSpaceFrom rule in the same manner, but sets the rule dimension, not the Enclosed value. The alias minOverlapDistance is also recognized.

constraintGroups/foundry/orderedSpacings/minOppExtension
This is handled similarly to the two rules above, but sets the Opposite clause of the MinSpaceFrom rule.

constraintGroups/LEFDefaultRouteSpec/interconnect/maxRoutingDistance
This provides the maxdist routing parameter (see A.6.4).

$\parbox{4in}{\tt constraintGroups/LEFDefaultRouteSpec/routingGrids/h... ...lPitch\newline constraintGroups/LEFDefaultRouteSpec/routingGrids/verticalPitch}$
These provide the pitch routing parameter (see A.6.4).

$\parbox{4in}{\tt constraintGroups/LEFDefaultRouteSpec/routingGrids/h... ...ffset\newline constraintGroups/LEFDefaultRouteSpec/routingGrids/verticalOffset}$
These provide the offset routing parameter (see A.6.4).

layerRules/routingDirections
This provides the preferred routing direction.

constraintGroups/foundry/spacings/minWidth
This maps to the width routing parameter (see A.6.4).