Device Blocks

Physical characteristics of devices which are candidates for extraction are specified in device blocks in the technology file. The device blocks are located in the technology file after the physical layer definitions. These specifications enable automated extraction of circuits from physical layouts.

Devices are specified in the technology file through a block of lines keyed by the word ``Device'' and ending with ``End''. An example is below:

Device
Name res
Prefix R_
Body R2
Contact + M2 I1B&R2
Contact - M2 I1B&R2 ...
Permute + -
Depth 1
Merge S
Measure Resistance Resistance
LVS Resistance
Spice %n% %c%+ %c%- %ms3%Resistance
Cmput Resistor %e%, resistance = %ms3%Resistance
Value %m%Resistance
End

There can be no text following Device in that line. The block must terminate with End.

The device block in the example specifies a resistor device:

• The resistor body consists of areas of layer R2.
• Contact is made to conductor M2 through a region of I1B (which represents a physical via).
• The resistor can have arbitrarily many contacts (... given in second Contact line). This will be decomposed into a network of two-terminal resistors by the extraction system.
• The (two) terminals are interchangeable (Permute given).
• Parts of the resistor can be found in subcells (Depth of 1).
• Two-terminal resistors in series and in parallel will be merged iteratively into simplified networks.
• The resistance of the structure will be measured and reported.

The keywords are described in detail below.

Template template_name argument ...
This will access the device template with the given template_name. Text from the template will be inserted into the current device block, after macro, variable, and argument substitution. For argument substitution, forms like ``$(_N)'', with N being a positive integer, will be replaced by the N'th argument, with any quote marks stripped. If an argument contains white space or other strange characters, it should be double-quoted.

The template can provide all of the keyword text for the current device block, or additional keywords from the list below can be provided to supplement the template. It may not be possible to redefine an alredy defined keyword however.

Name device_name
The device_name names the device, which should match a device cell name. The name can be that of a parameterized cell, or a regular device cell from the device library (device.lib) file, or a device cell from some other source. This line is mandatory.

Two or more device blocks can use the same name if they have different Prefix entries. This might be useful, for example, if there are two resistor layers in a process. A device block would be needed to describe resistors on each layer.

Prefix prefix
This is a prefix that is prepended when formulating the name for the device used in output. This is optional, as a prefix can also be defined in the output formatting. The first letter of the prefix should match the expectations of the SPICE simulator or other tools to be used. If two or more device definition blocks have the same Name field, they must have different Prefix fields. Further, each definition must have identical contact and bulk contact names, and order, and identical permutable contact names.

Body expression
The Body keyword specifies the ``core'' physical feature of the device. The specification is a layer expression. Each individual region where the expression is true defines a potential instance of the device. This keyword is mandatory.

Contact name layer expression [...]
For each contact of the device, there should be a Contact line. The first token following Contact is a name for the contact, which should match the corresponding name used in the node property of the device in the device library file. The second token is a layer name of a conductor layer which is used to contact the device. The remainder is an expression which identifies the contact area. The contact is identified as a region inside the device bounding box where the expression is true. Multiple contacts using the same expression can be given, and each will select a different region. The device bounding box is the bounding box of the body area, after the Bloat operation (see below).

If the Contact line ends with ``...'' (three periods) there can be more than one of that type of contact. Ordinarily, there is a one-to-one correspondence between contacts specified and contacts in the device instance. With the ellipses, device instances will include as many of that type of contact as can be found. Thus, such devices no longer have a fixed number of contacts. The ellipses can not appear in the first Contact line, but may appear in the second and/or subsequent Contact lines.

The ellipses feature presently supports multi-contact resistors. A multi-contact resistor is replaced internally by a network of two-terminal resistors, which are used in the netlist output. To enable multi-contact resistor support, the second contact specification in the resistor device block should end with ``...'', for example

Contact + M2 I1B&R2
Contact - M2 I1B&R2 ...

This specifies that as many of the second type of contact as can be found will be extracted. Without the ``...'' only two contacts would be extracted. The ellipses can not occur on the first contact line, but may occur on other lines, and may occur more than once, though no standard devices use this feature presently. In general, this implements device extraction with arbitrary numbers of certain contacts.

Internally, a conductivity matrix is computed from the body and contact geometry, and this is used to compute the effective values of the two-terminal resistors that are used to implement the multi-contact resistor. Resistors that would have very high values (larger than 100 times the smallest value) are not added, so that linear multi-contact resistors decompose as one would expect.

The decomposition occurs before the serial/parallel merging, so that the components of the decomposition are candidates for merging, if merging is enabled (see the Merge keyword below).

BulkContact tname level [name | bloat layername expression]
This is a special form of a contact specification that applies to well and substrate connections, which may be treated differently than other contacts. The tname is the contact name. This is followed by an integer level which determines how the contact is handled during extraction. Possible level values are as follows. The remaining entries in the line depend on the level. There can be at most one BulkContact line in the device description.

0
Check in cell during device extraction. This requires that a bloat value, layername, and expression follow the level number. The body bounding box is (logically) bloated by the bloat value given (in microns). Within the bloated area, a region where the expression (a layer expression) is dark, that is connected to the conductor layername must exist. If there are multiple areas, the one closest to the bounding box center is taken as the contact area. If there is no such area, the device will not be recognized. The search hierarchy depth for the contact is to all levels.

1
Ignore this in extraction. The level value must be followed by a name, which is the name of a global net. The contact will be assumed to connect to that global net. Use this mode only if it is absolutely certain that physically the bulk contact is connected properly, as this mode does no checking. Use this at your own risk.

2
Check deferred. This requires that a bloat value, layername, and expression follow the level number. During extraction and association, if the contact can't be resolved within its containing cell, level=2 contacts are ignored as for level=1.

During LVS, a special ``stamping'' test is run over the complete hierarchy, and any errors found are reported with the top-level cell. This test searches for unresloved level=2 contacts in the hierarchy. It will try and resolve the contact at the top level (thus taking account of all geometry in the hierarchy). If unsuccessful, the device location as reflected to the top level coordinates will be listed in the stamping report, and LVS will not succeed.

Bloat increment
This will expand the body bounding box by increment (in microns) for the purpose of identifying contacts. For example, a MOS transistor body is the intersection of CAA and CPG. The source and drain contacts can be specified as the regions of the body bounding box after a bloat that cover CAA but not CPG.

ContactsOverlap
Ordinarily, device contact areas can not overlap. The extracted contact areas are clipped against one another to enforce this. Giving this keyword allows overlap, which is necessary for some vertical device structures.

Permute name1 name2
The names are the names of contacts that can be permuted to enable association when comparing to a schematic. This applies to devices such as resistors, and to the source and drain of MOS devices, or to any device containing a contact pair that are geometrically identical to the extractor. There must be exactly two names following ``Permute'', and only one Permute line is allowed.

Depth depth
The depth is the hierarchy depth extracted for the device, default is 0, meaning all device structure should appear is the current cell. The value can be an integer, or `a' to look at the full hierarchy.

Find [device_name][.prefix]
This will cause a device with the given name and prefix to be searched for in the current device's bounding area, and added to an internal list. Any number of Find directives can be applied. If two or more directives look for the same name/prefix, they will return different instances. Currently, this is used only for identifying inductors in a mutual inductor device.

Merge [arg]
This optional keyword specifies how to handle parallel and series connected instances of the device for parameter extraction. There is an optional argument. Merging implies that multiple devices are combined internally and reported as single devices in netlists and SPICE output. If both parallel and series merging are enabled, the merging process is iterative, and will continue until no further merging is possible.

If no Merge keyword appears in the device block, no merging is done for that device. Only the first two characters of the arg are tested, case insensitively, and any remaining characters are ignored. Series merging will be enabled only for two-terminal devices that have the Permute keyword applied, i.e., typically resistors, capacitors, inductors.

arg	Merge
no arg	parallel
"s"	parallel and series
"ns" or "sn"	series
unrecognized	error

Merging can also be controlled by the variables NoMergeParallel and NoMergeSeries which are booleans which can be set with the !set command. The variables suppress merging of the indicated kind, parallel or series, for all devices.

Merging can also be suppressed on an individual device basis by applying a NoMerge property to an object that is used in the body of the device. This property can be added with the Property Editor.

Merging can lead to confusion, particularly when users are experimenting. Unless the aggregate has external connections, it is likely to be merged down to a single device in ways which may be surprising.

Example:
The Show computed parameters of selected device option of the Enable Select command mode in the Show/Select Devices panel from the Device Selection button in the Extract Menu is useful for displaying the values of extracted devices, and shows the effect of merging. When resistor networks are merged, Xic will merge series resistors if there are no other connections at the common node. Sometimes, this will lead to a configuration that is not intended or desired, for example if the desired end terminal of the network is connected to two resistors only, that node might be merged away. Xic will merge devices arbitrarily if there is insufficient information available to uniquely define how merging is to be done.

One way to prevent this from happening is to use temporary virtual terminals:

1. Switch to electrical mode.
2. Enter the subct side menu command.
3. Press Ctrl and click anywhere in the drawing window. A terminal marker will appear. Dismiss the Terminal Edit pop-up, and switch back to physical mode.
4. Press the Setup button in the Extract Menu to obtain the Extraction Setup panel. Press Edit Terminals in the panel. A terminal mark should appear to the lower left of the bounding box of the current cell.
5. Move the terminal mark to the desired network end terminal metal.

This node now has a (phony) terminal, so it won't be merged. Don't forget to go back and delete the terminal when done.

The way the parameters are computed upon merging is determined by the Measure keyword (see below). Series merging is applicable to resistor, capacitor, and inductor-type devices.

Measure Keyword	Parallel Action	Series Action
BodyArea	Sum	Sum
BodyPerim	Sum	Sum
BodyMinDimen	Min1	Min
CArea	Sum2	-
CPerim	Sum2	-
CWidth	-	-
CNWidth	-	-
CBWidth	Average	Sum
CBNWidth	Sum	Average
Resistance	Parallel Resistance	Sum
Inductance	Parallel Resistance	Sum
Mutual_Inductance	not implemented	not implemented
Capacitance	Sum	Parallel Resistance

Notes:
1) Although the minimum of the multiple sections is used, for MOS devices each value is typically the same.
2) If devices of the same type share a contact, the contact area and perimeter are divided equally between the devices.
The fields with `-' above are invalid, and return 0 if accessed.

The ``Merge M'' feature of earlier releases is no longer supported. This would average the parameters of parallel-connected MOS devices, and automatically add the ``M='' (multiplier) parameter to the SPICE output line. Now, the merging behavior is as described above, and no multiplier is automatically added to the SPICE line. The Sections measurement keyword (below) can be used to explicitly format the SPICE output to use the multiplier parameter, if desired.

Measure mname expression [precision]
The Measure keyword allows geometrical information to be extracted from the device, which is listed with the Dump Phys Netlist command in the Extract Menu and used in other commands in the Extract menu.

mname
A name for the parameter te be extracted. This is arbitrary but should be unique for the device. This is the name by which the particular measurement result is referenced.

precision
The optional precision is a non-negative integer which applies to comparing electrical and physical values in layout vs. schematic (LVS) testing. The default is 2 if not given. If the value given is n, then the two values must agree to a part in 10ⁿ , e.g., to within 1 percent for the default value of 2.

expression
The expression consists of an expression in the format recognized in scripts, where the variables are either the names from previously defined Measure lines (in the current device block) or the keywords below. The expression is evaluated during extraction yielding the result of the measurement. The math functions are available in the expression as are all of the math operators. There can be arbitrarily many Measure lines.

Below is a list of the ``primitive'' measurement tokens which can appear in the measurement expressions. In several cases, the token consists of three fields, separated by `.'. The additional fields supply modifiers to the primitive measurement indicated by the token name (the first field).

The basic unit of length is one micron.

Sections
This returns the number of components of the device, which will be greater than one if the device is an aggregate of several series or parallel-connected devices (Merge enabled).

BodyArea
The area of the region where the Body expression is true.

BodyPerim
The perimeter length where the Body expression is true.

BodyMinDimen
This is a minimum dimension computed using the body geometry. There are several ways that this can be computed, depending on other keywords and the device type. The default algorithm first decomposes the body shape into a trapezoid list. the mid-height width and height of each trapezoid is added to a histogram, weighted by the other value. For example, width=2, height=3 would add to the histogram 2 with weight 3, and 3 with weight 2. When done, the value with the largest weight will be taken as the BodyMinDimen. If a tie, the smaller value is used. This is effective on structures where a ``line width'' is an applicable concept.

However, if the SimpleMinDimen keyword is found, the BodyMinDimen will instead be the smallest width or height found. This was the default algorithm in releases prior to 3.1.6. The result of the simple algorithm is less useful, as, for example for a serpentine structure, it could be the line width, or the spacing.

There is yet another BodyMinDimen algorithm, associated with MOS devices and indicated by the ContactMinDimen keyword. With this keyword, and if a Permutes contact list is given, the BodyMinWidth will be the distance between the inside edges of the two contacts in the Permutes list. This is the default for recognized MOS devices, i.e., devices whose prefixes start with `m' or `M', and overrides SimpleMinDimen if both are applicable.

For MOS devices, where it is assumed that the gate length (source to drain) is constant, i.e., the gate is a strip that can meander arbitrarily, even forming a loop, for device size measurements, one can specify

length = BodyMinDimen
width = BodyArea/BodyMinDimen

The next four keywords have two optional trailing fields. The value in each field must be a single digit. The digit corresponds to a Contact, in order of appearance in the device block, starting with 0. If one or both fields is left off, the effective entry is 0. If both contacts are given the same digit, the second one is incremented. Thus, leaving off the trailing fields is equivalent to ".0.1". If the indices don't point to an existing contact, or are not single digits, the measurement will fail. These are illustrated in Figure 16.1.

The ``body bounding box'' is the rectangular region encompassing the Body objects, before any bloat.

CWidth[.n1.n2]
The width of the first contact, along a line connecting the first contact with the second contact.

CNWidth[.n1.n2]
The width of the first contact, normal to the line connecting the first contact to the second contact, measured at the contact bounding box midpoint.

CBWidth[.n1.n2]
The width between the first contact and the second contact, which lies over the body bounding box.

CBNWidth[.n1.n2]
The length of the line normal to the line between the first contact and the second contact, over the body bounding box, passing through the center of the body bounding box.

Example:

Contact s CAA CAA & !CPG
Contact d CAA CAA & !CPG
Contact g CPG CAA & CPG
Measure Length CBWidth.0.1 * 1e-6
Measure Width CBNWidth.0.1 * 1e-6

Note that the conversion to meters is included in the Measure lines in the example above.

The following two keywords contain two trailing fields, which are mandatory. The first field contains a contact index as above. The second field contains the name of a layer.

CArea.n1.lname
Construct a single polygon from the connected objects on the named layer, one of which intersects the bounding box of the given contact. The area of the polygon is returned. Note that the constructed polygon can extend outside of the device's bounding box. If the device being measured is merged, then the result is the sum of the results from each component.

CPerim.n1.lname
Measure the perimeter length of the polygon constructed as above. If the device being measured is merged, then the result is the sum of the results from each component.

When measuring with CArea/CPerim (for MOS ad/as/pd/ps), there is a test to see whether the area intersects other device contacts from the same device type. If a contact is shared between two devices, e.g., common active layer for two series-connected MOS devices, the following algorithm is invoked.

For the shared contact:

1. Compute the total contact area and perimeter for both devices.
2. Compute the area and perimeter for the contact area common to both devices.
3. Subtract 1/2 this value from the parameters computed in the first step.

This algorithm should work whether or not the devices are multi-component and merging is enabled.

Example:

Contact s CAA CAA & !CPG
Contact d CAA CAA & !CPG
Contact g CPG CAA & CPG
Measure AS CArea.0.CAA
Measure AD CArea.1.CAA
Measure PS CPerim.0.CAA
Measure PD CPerim.1.CAA

Resistance
Extract the resistance value (see below).

Capacitance
Extract the capacitance value. The returned capacitance value is given by the BodyArea times the capacitance per unit area, plus the BodyPerim times the capacitance per unit length. The capacitance values are specified in a Capacitance line in the layer block of one of the layers defining the device body, i.e., the layers mentioned in the Body line. If no body layer contains a Capacitance specification, or if both parameters are zero, an error results.

Inductance
Extract the inductance value (see below).

Mutual_Inductance
Extract the mutual inductance value. This is not yet implemented.

The internal device definition structure contains a flag that if set causes the device to be treated as a MOS transistor. There are a few MOS-specific tests and operations found in the extraction system, which are enabled by the flag. By default, the flag is set if the device Prefix starts with `m' or `M'.

There are also flags that are set if the device is determined to be n-type or p-type. Presently, we only set these for MOS devices. By default, if the device name begins with `p' or `P', the device is assumed to be p-type, otherwise it is taken as n-type.

NotMOS
If given, the flag that indicates that the device is a MOS transistor will not be set, as it would normally be if the Prefix starts with `m' or `M'.

MOS
If this keyword is given, the flag indicating that the device is a MOS transistor will be set. This overrides NotMOS.

NMOS
Flags will be set to indicate that the device is an n-type MOS transistor.

PMOS
Flags will be set to indicate that the device is a p-type MOS transistor.

Ntype
Flags will be set to indicate that the device is n-type. This is meaningful only for MOS transistors at present.

Ptype
Flags will be set to indicate that the device is p-type. This is meaningful only for MOS transistors at present.

SimpleMinDimen
When given, and the ContactMinDimen is not applied or not applicable, the BodyMinDimen measurement will be the smallest trapezoid width or height found in the decomposition of the body shape. This was the default algorithm in releases prior to 3.1.6, but a better algorithm is the new default.

ContactMinDimen [y/n]
This keyword has a dual purpose: to impose a MOS-like BodyMinDimen computation on other device types, and to turn off the use of this algorithm in MOS devices, which use this algorithm by default.

Recognized MOS devices are devices that have the internal flag set as mentioned above. The device must also have a Permutes list for this algorithm to apply. Most MOS devices have permutable source and drain contacts.

In recognized MOS devices with permutes, the default BodyMinDimen calculation is to set this to the distance between the inside edges of the two contacts listed in the Permutes list. Thus, the BodyMinDimen will always be the device length (source/drain spacing) even if the source-drain spacing is larger than the device width. The simple ``line width'' algorithm normally applied for the BodyMinDimen would be ambiguous as to whether the BodyMinDimen is the device length or width.

If ContactMinDimen n is given for a recognized MOS device, the line width algorithm will be used. The ``n'' can actually be one of many tokens that indicate negativity, such as ``no'', ``false'', ``off'', ``0'', etc., case insensitive, but the token must appear.

For devices that are not recognized MOS devices, the line width BodyMinDimen algorithm is used by default. However, if ContactMinDimen y is given, and the device has a Permutes list, the BodyMinDimen will be computed as for MOS devices. The ``y'' can actually be missing, or can be one of many possible tokens that indicate truth, such as ``yes'', ``true'', ``on'', ``1'', etc., case insensitive.

LVS measure_expr [spice_name]
This keyword instructs Xic to perform a parameter comparison as part of LVS. The measure_expr is either one of the names used for a Measure statement in the device block, or a single-quoted expression involving constants and names from Measure statements. The spice_name, if given, is the token used in SPICE element lines to designate the parameter, e.g., ``l'', ``w'', ``area''. This can be blank if comparing to an element value which is given as a leading number, i.e., resistance, capacitance, etc. The LVS directives must appear after the referenced Measure line.

Examples:

Measure Area BodyArea*1e-12
LVS Area area

Measure Resistance Resistance
LVS Resistance

Any number of LVS lines can appear in a device block.

Figure 16.1: The distances returned by the various width measurement keywords to the device block Measure line.

Spice specification_args
The Spice keyword specifies the format for the SPICE output part of the listing from the Dump Phys Netlist command in the Extract Menu. The specification is copied verbatim, except for the following substitutions:

\ n
The character sequence ` \ n' is replaced by a newline in the expanded text. Note that the next token should probably begin with the SPICE continuation character `+' for the SPICE output to be interpreted correctly.

\ t
The character sequence ` \ t' is replaced by a tab character.

%c%cname
The cname is a contact name (from a Contact line). This token is replaced with the group number of the contact.

%m[g | s[N] | f[N] | e[N]]%mname
The mname is a name from a Measure line. The token is replaced with the result of that measurement. One of the characters s, g, f, e can follow the `m'. The s, f, e can be followed by an optional digit. These select the format of the printed result.

g
Use the ``best'' numeric format (the default if no modifier given).

sN
Use SPICE abbreviations, with N decimal places.

fN
Use fixed point notation, with N decimal places.

eN
Use exponential notation, with N decimal places.

If N is not given, the default is 5 digits.

Above, cname and mname can be followed directly by `%' and other text, for a concatenation function. For example ``L=%m%Length%u'' might be replaced with ``L=.8u''.

%n%
This token is replaced with a name for the device, which consists of the Prefix (if given) followed by an index count for the device type.

%p lname pnum%
This token is replaced by the text of a physical property. The lname is the name of a layer, and space after the `p' is optional. The pnum is a non-negative integer. Each of the objects on lname that intersect the device bounding box is checked for a property with number pnum. The string of the first such property found is used. This enables property text to appear in device output, in particular it provides a means to coerce a value or other parameter.

%e%
If the electrical dual of the physical device is known, the %e% is replaced by the name of the electrical device. If no dual is known, the behavior is the same as %n%.

%f%
The substitution %f% is equivalent to %e% except that if the dual device is unknown, the token is simply ignored.

Each of the substitution tokens can take an optional integer after the first %, which indicates that the token refers to the device in the n'th Find line (0 is the same as no integer).

Example:

Device
Name mut
Prefix K
...
Find ind
Find ind
Spice %n% %1n% %2n% ...

The Spice line prints the name of the mut device, followed by the names of the two inductors.

%model%
Replaced by contents of the Model line (see below).

%value%
Replaced by contents of the Value line (see below).

%param% or %initc%
Replaced by contents of the Param line (see below).

The Spice line is used in Dump Phys Netlist output and internally by Source Physical command.

Cmput specification_args
This specifies the format used in printing the device parameters from the Show computed parameters of selected device option of the Enable Select command mode in the Show/Select Devices panel The substitutions are exactly as those of the Spice keyword. For example:

Device
Name res
...
Measure Resistance Resistance
Cmput Resistance = %m%Resistance ohms
End

$\parbox{4in}{\sf Model {\it specification\_args}\\ Value {\it specification\_args}\\ Param {\it specification\_args} }$
These keywords specify a format string to use when creating ``property strings'' from the extracted parameters of a physical device, to be used for comparison or updating the properties of the corresponding electrical device. These are used in the Source Physical command, and in the Show elec/phys comparison of selected devices option of the Enable Select mode in the Show/Select Devices panel. This panel is brought up by the Device Selections button in the Extract Menu.

The format is the same as is described for the Spice line, however the escapes %model%, %value%, and %param% are not recognized.

The Model, Value, and Param lines are used internally when comparing physical devices to their electrical counterparts. This is done, for example, in the Show elec/phys comparison of selected devices option of the Enable Select mode in the Show/Select Devices panel. This panel is brought up by the Device Selections button in the Extract Menu.

The Set varname = something construct in the technology file can apply to lines in device blocks, however the Set keyword must appear outside and before the block. Device block lines can contain $(varname) tokens, which are replaced with something before the line is parsed.

The format specifications for the Spice, Cmput, etc. lines can contain the eval(...) construct. The argument to eval is evaluated as a mathematical expression, and the result replaces the entire construct. Unlike elsewhere in the technology file, in these lines this construct is evaluated when the line is used, and not when the technology file is read.

The extraction mechanism can be tested with the !find command, or with the device listing capability in the Show/Select Devices panel from the Device Selections button in the Extract Menu.

Xic contains functionality for accurately calculating resistor values of arbitrarily shaped resistors. Resistance extraction is accomplished by dividing the resistor logically into a regular grid. The center of each grid is a ``node'' that is connected by resistance to adjacent nodes. Thus, the problem becomes one of solving a large lumped resistor mesh.

Best accuracy is obtained when the grid falls on all the resistor and contact boundaries. It is not possible to find such a grid in general, however if a layout grid is used and all corners are on-grid, and all edges are Manhattan, then tiling will be possible. It may be the case that tiling is possible, but the tile is so small that the computation time is unacceptable.

For structures that can't be tiled efficiently, a set of edge-dependent heuristics is used to modify the matrix elements to account for the local area deficit or surplus.

There are four variables that can be used to configure the extractor. The default values lean toward speed over accuracy. By default, tiling is not attempted, and the grid spacing will be selected so that each resistor contains 1000 grid cells.

RLSolverDelta
Value: floating point > = 0.01.
It this value is set, the resistance/inductance extractor will assume this grid spacing, in microns. The number of grid cells enclosed in the device will increase for physically larger devices, so that larger devices will take longer to extract. If this variable is set, the other RLSolver variables are ignored. Setting this variable may be appropriate if all resistors are ``small'' and dimensions conform to a layout grid.

RLSolverTryTile
Value: boolean.
If set, the extractor will attempt to use a grid that will fall on every edge of the device body and contacts. The device and contact areas must be Manhattan for this to work. If such a grid can be found, and the number of grid cells is a reasonable number, this will give the most accurate result.

RLSolverGridPoints
Value: integer 10-100000.
When not tiling (RLSolverTryTile is not set), this sets the number of grid points used for resistance/inductance extraction. This number will be the same for all device structures, so that computation time per device is nearly constant. Higher numbers give better accuracy but take longer. The value used if not set is 1000.

RLSolverMaxPoints
Value: integer 1000-100000.
When tiling (RLSolverTryTile is set), the maximum number of grid cells is limited to this value. If the tile is too small, it will be increased in size to keep the count below this value, in which case the tiling will not have succeeded so there may be a small loss of accuracy. Using a large number of grid points can take a long time. The value used if not set is 50,000.

The resistor solver is accessed through the device block Measure keyword ``Resistance'', for example:

Device
Name res
...
Measure value Resistance
End

By including the ``Measure value Resistance'', all resistances may be extracted and the values will appear in the output of the Dump Phys Netlist command. When computing the resistance, the layers in the Body specification are checked for an Rsh specification, or alternatively a Rho or Sigma specification along with a Thickness specification. If the resistance parameters are not found, an error results. Unlike releases prior to 3.1.6, there is no default resistance.

Xic also contains functionality to measure conductor inductance values. Inductance is extracted using an algorithm similar to resistance, i.e., square counting, but other factors are included to enhance accuracy. This assumes ``microstripline'' geometry, meaning a conductor separated from a ground plane by a uniform dielectric. The Measure keyword is ``Inductance''. The inductance per square is derived from the microstrip parameters for the layer, as provided with the Tline specification. A Tline specification must be given to one of the device body layers, or an error results.

Presently, the recommended way to set up inductors for extraction is through the use of three additional layers. These layers can have any name but will have the following names in this discussion:

LB
Used to outline the inductor, will surround the region of a conductor where inductance is to be measured.

LC
Identifies the inductor contacts (inside LB and on the conductor).

LX
Bisects the conductor into two areas to provide separate groups for the two contacts.

Figure 16.2: Illustration of the configuration of layers LB, LC, and LX for extracting inductance from a conducting strip. The LX ensures terminal assignments to different groups.

These layers have been added to the xic_tech.hyp file provided. The ``Exclude LX'' clause must be added to the Conductor specification of the conductors to be extracted.