Product Documentation
LEF/DEF 5.8 Language Reference
Product Version 5.8, September 2022

1


LEF Syntax

This chapter contains information about the following topics:

About Library Exchange Format Files

A Library Exchange Format (LEF) file contains library information for a class of designs. Library data includes layer, via, placement site type, and macro cell definitions. The LEF file is an ASCII representation using the syntax conventions described in “Typographic and Syntax Conventions”.

General Rules

Note the following information about creating LEF files:

Character Information

For information, see Character Information in the DEF Syntax chapter.

Name Escaping Semantics for LEF/DEF Files

For information, see Name Escaping Semantics for Identifiers in the DEF Syntax chapter.

Managing LEF Files

You can define all of your library information in a single LEF file; however this creates a large file that can be complex and hard to manage. Instead, you can divide the information into two files, a “technology” LEF file and a “cell library” LEF file.

A technology LEF file contains all of the LEF technology information for a design, such as placement and routing design rules, and process information for layers. A technology LEF file can include any of the following LEF statements:

     [VERSION statement] 
[BUSBITCHARS statement]  
[DIVIDERCHAR statement]   
[UNITS statement]
[MANUFACTURINGGRID statement]
[USEMINSPACING statement]
[CLEARANCEMEASURE statement ;]
[PROPERTYDEFINITIONS statement]
[FIXEDMASK ;]
[LAYER (Nonrouting) statement
 | LAYER (Routing) statement] ...
[MAXVIASTACK statement]
[VIA statement] ... 
[VIARULE statement] ... 
[VIARULE GENERATE statement] ...
[NONDEFAULTRULE statement] ...
[SITE statement] ...
[BEGINEXT statement] ...
[END LIBRARY]

A cell library LEF file contains the macro and standard cell information for a design. A library LEF file can include any of the following statements:

     [VERSION statement]
[BUSBITCHARS statement]
[DIVIDERCHAR statement]
[VIA statement] ...
[SITE statement]
[MACRO statement
  [PIN statement] ...
  [OBS statement ...] ] ...
[BEGINEXT statement] ...
[END LIBRARY]

When reading in LEF files, always read in the technology LEF file first.

Order of LEF Statements

LEF files can contain the following statements. You can specify statements in any order; however, data must be defined before it is used. For example, the UNITS statement must be defined before any statements that use values that are dependent on UNITS values, LAYER statements must be defined before statements that use the layer names, and VIA statements must be defined before referencing them in other statements. If you specify statements in the following order, all data is defined before being used.

     [VERSION statement]
[BUSBITCHARS statement]
[DIVIDERCHAR statement]
[UNITS statement]
[MANUFACTURINGGRID statement]
[USEMINSPACING statement]
[CLEARANCEMEASURE statement ;]
[PROPERTYDEFINITIONS statement]
[FIXEDMASK ;]
[  LAYER (Nonrouting) statement
 | LAYER (Routing) statement] ...
[MAXVIASTACK statement]
[VIARULE GENERATE statement] ...
[VIA statement] ...    
[VIARULE statement] ...
[NONDEFAULTRULE statement] ...
[SITE statement] ...
[MACRO statement
  [PIN statement] ...
  [OBS statement ...]] ...
[BEGINEXT statement] ...
[END LIBRARY]

LEF Statement Definitions

The following definitions describe the syntax arguments for the statements that make up a LEF file. Statements are listed in alphabetical order, not in the order they should appear in a LEF file. For the correct order, see “Order of LEF Statements”.

Bus Bit Characters

[BUSBITCHARS "delimiterPair" ;]

Specifies the pair of characters used to specify bus bits when LEF names are mapped to or from other databases. The characters must be enclosed in double quotation marks. For example:

BUSBITCHARS "[]" ;

If one of the bus bit characters appears in a LEF name as a regular character, you must use a backslash (\) before the character to prevent the LEF reader from interpreting the character as a bus bit delimiter.

If you do not specify the BUSBITCHARS statement in your LEF file, the default value is “[]”.

Clearance Measure

[CLEARANCEMEASURE {MAXXY | EUCLIDEAN} ;]

Defines the clearance spacing requirement that will be applied to all object spacing in the SPACING and SPACINGTABLE statements. If you do not specify a CLEARANCEMEASURE statement, euclidean distance is used by default.

MAXXY

Uses the largest x or y distances for spacing between objects.

EUCLIDEAN

Uses the euclidean distance for spacing between objects. That is, the square root of x2 + y2.

Divider Character

[DIVIDERCHAR "character" ;]

Specifies the character used to express hierarchy when LEF names are mapped to or from other databases. The character must be enclosed in double quotation marks. For example:

DIVIDERCHAR "/" ;

If the divider character appears in a LEF name as a regular character, you must use a backslash (\) before the character to prevent the LEF reader from interpreting the character as a hierarchy delimiter.

If you do not specify the DIVIDERCHAR statement in your LEF file, the default value is “/”.

Extensions

[BEGINEXT “tagextension 
ENDEXT] 

Adds customized syntax to the LEF file that can be ignored by tools that do not use that syntax. You can also use extensions to add new syntax not yet supported by your version of LEF/DEF, if you are using version 5.1 or later.

extension

Specifies the contents of the extension.

tag

Identifies the extension block. You must enclose tag in double quotation marks (“”).

Example 1-1 Extension Statement

BEGINEXT “1VSI Signature 1.0” 
CREATOR “company name”
DATE “timestamp”
REVISION “revision number”
ENDEXT

Here, tag is 1VSI Signature 1.0 and extension is all the remaining text before ENDEXT, including any newline characters. In this example, the extension string is as follows:

CREATOR “company name”
DATE “timestamp” 
REVISION “revision number”

FIXEDMASK

[FIXEDMASK ;]

Does not allow mask shifting. All the LEF macro pin mask assignments must be kept fixed and cannot be shifted to a different mask. The LEF macro pin shapes should all have MASK assignments, if FIXEDMASK is present. In addition, macro OBS should all have MASK assignments unless they have SPACING override. This statement should be included before the LAYER statements.

For example,

...
MANUFACTURINGGRID 0.001 ;
FIXEDMASK ;
LAYER xxx

Some technologies do not allow mask shifting for cells using multi-mask patterning. For example, the pin and routing shapes are all pre-colored and must not be shifted to other masks.

Layer (Cut)

Defines cut layers in the design. Each cut layer is defined by assigning it a name and design rules. You must define cut layers separately, with their own layer statements. For details, see the following chapter:

Layer (Implant)

Defines implant layers in the design. Each layer is defined by assigning it a name and simple spacing and width rules. For details, see the following chapter:

Layer (Masterslice or Overlap)

Defines masterslice (non-routing) or overlap layers in the design. For details, see the following chapter:

Layer (Routing)

Defines routing layers in the design. Each layer is defined by assigning it a name and design rules. You must define routing layers separately, with their own layer statements. For details, see the following chapter:

Library

Defining Library Properties to Create 32/28 nm and Smaller Nodes Rules

You can include library properties in your LEF file to create 32/28 nm and smaller nodes rules that currently are not supported by existing LEF syntax. The properties are specified inside the PROPERTYDEFINITIONS statements.

All properties use the following syntax within the LEF PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LAYER propName STRING ["stringValue"] ;
END PROPERTYDEFINITIONS

The property definitions for the library properties are as follows:

PROPERTYDEFINITIONS
   LIBRARY LEF58_ANTENNAMAXCUMAREA STRING ;
   LIBRARY LEF58_ANTENNAMAXGATEAREA STRING ;
   LIBRARY LEF58_ANTENNAMODELGROUP STRING ;
   LIBRARY LEF58_CELLEDGESPACINGTABLE STRING ;
   LIBRARY LEF58_CELLVARIANTS STRING ;
   LIBRARY LEF58_CONSTRAINTLENGTH STRING ;
   LIBRARY LEF58_CUTMASKTRACK STRING ;
   LIBRARY LEF58_FINFET STRING ;
   LIBRARY LEF58_IMPLANTGROUP STRING ;
   LIBRARY LEF58_LAYERMASKSHIFT STRING ;
   LIBRARY LEF58_MAXFLOATINGAREA STRING ;
   LIBRARY LEF58_MAXVIASTACK STRING ;
   LIBRARY LEF58_METALWIDTHTRACK STRING ;
   LIBRARY LEF58_METALWIDTHVIAMAP STRING ;
   LIBRARY LEF58_OALAYERMAP STRING ;
   LIBRARY LEF58_PGVIATRACK STRING ;
   LIBRARY LEF58_STACKVIALAYERRULE STRING ;
   LIBRARY LEF58_STACKVIARULE STRING ;
   LIBRARY LEF58_TAPDISTANCE STRING ;
   LIBRARY LEF58_TAPDISTANCERULE STRING ;
   LIBRARY LEF58_TRIMMETALTRACK STRING ;
   LIBRARY LEF58_VOLTAGEMODE STRING ;
END PROPERTYDEFINITIONS

Antenna Maximum Cumulative Area Rule

You can create an antenna maximum cumulative area rule to specify the maximum cumulative area of all layers to gate, which is not connected to the diffusion diode.

You can define an antenna maximum cumulative rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_ANTENNAMAXCUMAREA STRING
"ANTENNAMAXCUMAREA value [RANGE bottomLayer topLayer]
[CUTLAYERONLY]
;" ;
END PROPERTYDEFINITIONS

Where:

ANTENNAMAXCUMAREA value

Specifies the maximum possible cumulative area of all layers, which is not connected to the diffusion diode, to be less than or equal to value. This would include floating metal that does not necessarily connect to a gate yet. The gate connection is done through a metal layer above the floating metal.

Type: Float, specified in microns

CUTLAYERONLY

Specifies a maximum possible cumulative area only on cut layers.

RANGE bottomLayer topLayer

Specifies the maximum possible cumulative area between the given bottomLayer and topLayer.
Type: Float, specified in microns squared

Antenna Maximum Cumulative Area Rule Example

Antenna Maximum Gate Area Rule

You can create an antenna maximum gate area rule to specify the maximum total area of all the antenna gate areas connected on any routing layer on the given antenna model.

You can define an antenna maximum gate area rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_ANTENNAMAXGATEAREA STRING
"ANTENNAMAXGATEAREA {OXIDE1 | OXIDE2 | OXIDE3 | OXIDE4 | OXIDE5
| ... | OXIDE32} max_area
; " ;
END PROPERTYDEFINITIONS

Where:

ANTENNAMAXGATEAREA {OXIDE1 | OXIDE2 | OXIDE3 | OXIDE4 | OXIDE5
| ... | OXIDE32}
max_area
;

Specifies that the sum of all the antenna gate areas connected on any routing layer must be less than or equal to max_area on the given antenna model.

Type: Float, specified in microns squared

Antenna Model Group Rule

You can define an antenna model group rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_ANTENNAMMODELGROUP STRING
"ANTENNAMODELGROUP OXIDEx MODEL {OXIDEy}...[GATEONLY]
;" ;
END PROPERTYDEFINITIONS

Where:

ANTENNAMODELGROUP OXIDEx MODEL {OXIDEy}...

Specifies an antenna model group, which would be applied to all cut and routing layers, to combine all of the given OXIDEy in antenna consideration. OXIDEx would be considered when pins of all the OXIDEy models are connected and the individual OXIDEy models would be ignored. When some but not all of the OXIDEy models are connected, each of the individual OXIDEy models are checked separately and the OXIDEx model is ignored.

Type: String

GATEONLY

Specifies that the antenna model group applies only to the pattern that metal is connected to a gate, and ANTENNAAREARATIO, ANTENNACUMAREARATIO, ANTENNASIDEAREARATIO, and ANTENNACUMSIDEAREARATO rules should be checked.

Antenna Model Group Rule Examples

Constraint Length Rule

You can create a constraint length rule to define the horizontal and vertical length of the concatenated constraint area. You can define a constraint length rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_CONSTRAINTLENGTH STRING
"CONSTRAINTLENGTH length {MAX|MIN} [HORIZONTAL|VERTICAL] 
      [EXCEPTABUTTED] [WIDTH minWidth]
      CONSTRAINTAREATYPE {typeName | VERTICALCELLEDGESTACK
            | HORIZONTALCELLEDGESTACK}
      ;" ;
END PROPERTYDEFINITIONS

Where:

CONSTRAINTLENGTH length {MAX|MIN}
CONSTRAINTAREATYPE
typeName

Specifies the horizontal and vertical length of the concatenated constraint area with type typeName defined in CONSTRAINTAREATYPE in MACRO must be less than length in MAX or greater than length in MIN.

Type: Float, specified in microns

EXCEPTABUTTED

Specifies that the rule does not apply if there is an abutted shape from another cell in the orthogonal direction of the length constraint being checked.

HORIZONTAL|VERTICAL

Specifies that the constraint length rule applies only on the given direction of either HORIZONTAL or VERTICAL.

HORIZONTALCELLEDGESTACK

Specifies that aligning any horizontal (top or bottom) cell edges would be subjected to this length constraint. MAX and HORIZONTAL must be defined for this predefined constraint type, which does not require CONSTRAINTAREATYPE to be defined in any MACRO.
Type: Float, specified in microns

VERTICALCELLEDGESTACK

Specifies that aligning any vertical (right or left) cell edges would be subjected to this length constraint. MAX and VERTICAL must be defined for this predefined constraint type, which does not require CONSTRAINTAREATYPE to be defined in any MACRO.
Type: Float, specified in microns

WIDTH minWidth

Specifies that the rule applies only to the portion of a shape with width greater than or equal to minWidth.

Figure 1-2 Illustration of Constraint Length Rule

Figure 1-3 Illustration of Constraint Length Rule with WIDTH

Cell Edge Spacing Table Rule

You can create a cell edge spacing table rule to define a spacing table between two macro edges having different edge types.

This cell edge spacing table must be defined before reading in the MACRO definition with defined EDGETYPE in cell LEF files.

You can define a cell edge spacing table rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_CELLEDGESPACINGTABLE STRING
"CELLEDGESPACINGTABLE [NODEFAULT]
{EDGETYPE {edgeType1 | DEFAULT}
{edgeType2 | DEFAULT} [EXCEPTABUTTED]
[EXCEPTNONFILLERINBETWEEN]
[OPTIONAL | SOFT | EXACT] spacing} ...
;...” ;
END PROPERTYDEFINITIONS

Where:

CELLEDGESPACINGTABLE
{EDGETYPE {
edgeType1 | DEFAULT}
{
edgeType2 | DEFAULT} spacing}

Defines a spacing table between a macro edge with type edgeType1 and another macro edge with type edgeType2. The spacing is measured perpendicular from the edges. The DEFAULT keyword represents a macro edge without a type. If there is no spacing defined between the two types, it indicates that there is no spacing constraint (or 0.0 μm) between them.
Type: Float, specified in microns

EXACT

Specifies that it is a violation only when the spacing is exactly equal to spacing.

EXCEPTABUTTED

Specifies that two abutted macros of the given edge types are also allowed.

EXCEPTNONFILLERINBETWEEN

Specifies that the rule does not apply if there is, at least, one non-filler logic cell between the two constrained edges.

NODEFAULT

Specifies that DEFAULT should not be defined in the spacing table, and all the edges of any standard cell macros (with a SITE that is CLASS CORE) must have EDGETYPE property defined on both sides.

OPTIONAL

Specifies that the corresponding spacing constraints are optional. Users can use certain placement option to indicate whether those constraints should be observed or not.

SOFT

Specifies that the corresponding spacing constraints are soft. This means that the tool has the freedom to honor the constraint with certain efforts. If the constraint will disturb the placement quality too much, the tool can choose to ignore the constraint.

Cell Edge Spacing Table Rule Examples

Cell Variants Rule

You can create a cell variants rule to specify the placement locations of electrically equivalent (EEQ) cells.

You can define a cell variants rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_CELLVARIANTS STRING
"CELLVARIANTS variantTotalNum
[STARTVARIANT startVariant [XFLIPSTARTVARIANT startVariant]]
YFLIPMAP {flippedVariantNum siteVariantNum}...
[XFLIPMAP {cellVariantNum siteVariantNum}... ]
;" ;
END PROPERTYDEFINITIONS

Where:

CELLVARIANTS variantTotalNum [STARTVARIANT startVariant]
YFLIPMAP {
flippedVariantNum siteVariantNum}...

Specifies the total number of variants of electrically equivalent (EEQ) cells as variantTotalNum. The original cell master MACRO without the EEQ construct will always have an implicit variant number of 1. For each cell with EEQ, there should always be variantTotalNum - 1 number of MACRO with EEQ VARIANT, where EEQ refers back to the original cell master and the VARIANT number should be between 2 and variantTotalNum. The leftmost placement site of core area is labeled as variant 1 or startVariant if STARTVARIANT is defined. The subsequent sites range from 2 to variantTotalNum or startVariant % variantTotalNum + 1 to (startVariant + variantTotalNum - 2) % variantTotalNum + 1 and repeat back to 1 or startVariant. The non-Y-flipped instances should be placed such that the cell variant number matches the site variant number. Cells without any EEQ can be placed on any site.

YFLIPMAP defines which Y-flipped variant number, flippedVariantNum, should be placed on the site variant, siteVariantNum, when an instance is Y-flipped. There should be variantTotalNum pairs of variant values defined. The variant pair values should be symmetrical. That is, if flippedVariantNum of V1 is placed on siteVariantNum of V2, flippedVariantNum of V2 is placed on siteVariantNum of V1.
Type: Integer

Typically, this cell variant rule may vary for different cell libraries/heights, and this library property would likely be defined in a cell LEF or side LEF file, instead of a tech LEF file.

XFLIPMAP {cellVariantNum siteVariantNum}...

Specifies that the number of site variants, variantTotalNum, would be divided by two on each row. This means that variantTotalNum should be even and site variants would alternate between 1 and variantTotalNum/2 on each row. Only cell variants defined in cellVariantNum with a non-zero value in siteVariantNum could be placed on the MX rows, and they would be placed on the corresponding siteVariantNum. Only cell variants defined in cellVariantNum with a zero value in siteVariantNum could be placed on the R0 rows. There should be variantTotalNum pairs of variant values defined.

Type: Integer

XFLIPSTARTVARIANT startVariant

Specifies the leftmost placement site of the core area on the MX rows to be startVariant. STARTVARIANT would define the starting variant on the R0 rows. XFLIPSTARTVARIANT should only be defined along with XFLIPMAP.

Type: Integer

Cell Variants Rule Examples

Cut Mask Track Rule

You can create a cut mask track rule to specify a preferred cut mask vertical track for the mask of the cell master cuts.

You can define a cut mask rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_CUTMASKTRACK STRING
“CUTMASKTRACK cutLayer MASK maskNum OFFSET offset PITCH pitch
;” ;
END PROPERTYDEFINITIONS

Where:

CUTMASKTRACK cutLayer MASK maskNum OFFSET offset PITCH pitch

Specifies a preferred cut mask vertical track that the mask of the cell master cuts should follow. This construct is applied to all macros with CLASS CORE. cutLayer should be a cut layer with multiple masks using the MASK construct. maskNum defines the mask of the first track with offset from the cell origin of a cell master. Then, the subsequent track mask would be alternated with pitch being the track pitch. Cuts that are less than same-mask spacing apart should be clustered as a group, and the cut masks within a group are dependent on each other. However, the mask of an anchor cut in a group could be any mask. Once the anchor cut mask is picked, the mask of the rest of the cuts is determined. The cell architecture should have all of the center of cuts on the given tracks. The mask of the anchor cut should be picked to follow the track color.
Type: Floats, specified in microns

Cut Mask Track Rule Example

The following example indicates that the preferred cut mask vertical track for the mask of the cell master cuts is mask 1:

PROPERTYDEFINITIONS
LIBRARY LEF58_CUTMASKTRACK STRING "
CUTMASKTRACK VIA1 MASK 1 OFFSET 0.15 PITCH 0.2
; ";
END PROPERTYDEFINITIONS

Figure 1-9 Illustration of the Cut Mask Track Rule

FinFET Rule

You can create a FinFET rule to specify the FinFET pitch to be pitch.

You can define a FinFET rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_FINFET STRING
"FINFET
PITCH pitch [OFFSET offset] {HORIZONTAL|VERTICAL}
[NOCORECELL]
;" ;
END PROPERTYDEFINITIONS

Where:

FINFET
PITCH
pitch [OFFSET offset] {HORIZONTAL | VERTICAL}

Specifies the FinFET pitch to be pitch, which starts at the offset, if specified, or zero from the origin of the design. The HORIZONTAL/VERTICAL keywords mean that the FinFET pitch is used to define the legal Y/X values of the placement grid that all cells, blocks, and IOs must align to (specifically, the origin of every cell must be aligned to the legal Y/X values), in order to guarantee all the FinFETs inside are aligned properly. The X/Y value of the placement grid is derived from the standard cell site width and only applies to standard cells. The cell row height should typically be multiple of the FinFET pitch.
Type: Floats, specified in microns

NOCORECELL

Specifies that the FinFET grid does not apply to standard cells with MACRO with CLASS CORE.

FinFET Rule Example

The following example indicates that the FinFET y pitch is 0.108 µm:

PROPERTYDEFINITIONS
LIBRARY LEF58_FINFET STRING "
    FINFET
      PITCH 0.108 HORIZONTAL ; ";
END PROPERTYDEFINITIONS

Implant Group Rule

You can create an implant group rule to specify rules that apply for all the shapes on an implant layer.

You can define an implant group rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_IMPLANTGROUP STRING
"IMPLANTGROUP groupName
LAYER {layerName}... BASEDLAYER basedLayerName
;" ;
END PROPERTYDEFINITIONS

Where:

IMPLANTGROUP groupName 
LAYER {
layerName}... BASEDLAYER basedLayerName

Specifies that the combined shapes on all of the given layers in layerName, which must be an implant layer, must follow all of the rules on basedLayerName.

Implant Group Rule Example

PROPERTYDEFINITIONS
LIBRARY LEF58_IMPLANTGROUP STRING “
IMPLANTGROUP GROUP1 LAYER VT1 VT2 BASEDLAYER VT1 ;
IMPLANTGROUP GROUP2 LAYER VT1 VT3 BASEDLAYER VT1 ; “ ;
END PROPERTYDEFINITIONS

In this example, the combined shapes on VT1 and VT2 and the combined shapes on VT1 and VT3 must follow the rules on VT1.

Layer Mask Shift Rule

You can create a layer mask shift rule to specify that mask could be shifted on the given layers.

You can define a layer mask shift rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_LAYERMASKSHIFT STRING
"LAYERMASKSHIFT layer1 [layer2 ...]
     [MACROCLASS { RING | BLOCK | PAD | CORE | ENDCAP }...]
     ;" ;
END PROPERTYDEFINITIONS

Where:

LAYERMASKSHIFT layer1 [layer2 ...]
[MACROCLASS { RING | BLOCK | PAD | CORE | ENDCAP }...]

Specifies that a mask could be shifted only on the given layers. If MACROCLASS is also specified, only the given layers on the MACRO with the given classes allow color shifting. If this LAYERMASKSHIFT construct is defined, none of the macros should define LAYERMASKSHIFT. In addition, LAYERMASKSHIFT is treated as an exemption to FIXEDMASK, which should be defined as a library property or on individual macros.

Type: String

Layer Mask Shift Rule Examples

Maximum Floating Area Rule

Maximum area rules exist for floating metal shapes that are not connected to a diffusion or polysilicon gate. Similar to process antenna rules, maximum floating area rules apply only to the current layer and any lower layers (that is, all layers that have been fabricated up to the layer of interest). Maximum floating area rules can be used to avoid shorts between floating and non-floating metal wires that are caused by arcing due to charge buildup during processing steps.

You can create a global maximum floating area rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_MAXFLOATINGAREA STRING
"MAXFLOATINGAREA maxArea
{SINGLELAYER | CONNECTED | ALLCONNECTED} minRoutingLayer maxRoutingLayer
[[LAYERS minRoutingLayer maxRoutingLayer]
SPACING minSpacing [PARSPACING minParSpacing minParallelLength ...]] ... ;" ;
END PROPERTYDEFINITIONS

Where:

ALLCONNECTED minRoutingLayer maxRoutingLayer

Indicates that the rule applies to the connected area of floating metal shapes connected together on each layer between minRoutingLayer and maxRoutingLayer inclusive. The total connected area on the current and lower layers must be less than or equal to maxArea, or meet the minimum spacing to other grounded shapes on this layer and all lower-connected layer shapes. The names you specify for minRoutingLayer and maxRoutingLayer must be two previously defined LEF routing layers.

CONNECTED minRoutingLayer maxRoutingLayer

Indicates that the rule applies to the area of floating metal shapes connected together on each layer between minRoutingLayer and maxRoutingLayer inclusive. The connected area on a current layer must be less than or equal to maxArea, or meet the minimum spacing to other grounded shapes on this layer and all lower connected layer shapes. The names you specify for minRoutingLayer and maxRoutingLayer must be two previously defined LEF routing layers.

LAYERS minRoutingLayer maxRoutingLayer

Indicates that layers between minRoutingLayer and maxRoutingLayer inclusive must meet the specified SPACING rules. The names you specify for minRoutingLayer and maxRoutingLayer must be previously defined LEF routing layers, and can be the same layer.

MAXFLOATINGAREA maxArea

Indicates that floating metal shapes must have a total area that is less than or equal to maxArea.
Type: Float, specified in units of microns squared

Floating metal is defined as metal on the current layer that cannot trace a path to a diffusion connection or polysilicon gate, using only same-layer or lower-layer metal connections. Grounded metal is defined as metal that can connect to a diffusion connection or polysilicon gate using only same-layer or lower-layer connections.

Note: The MAXFLOATINGAREA rule depends on the existing LEF MACRO PIN ANTENNADIFFAREA and ANTENNAGATEAREA statements to indicate which pins are connected to diffusion or polysilicon gates.

You can have two MAXFLOATINGAREA statements: one for SINGLELAYER, and one for CONNECTED or ALLCONNECTED.

PARSPACING minParSpacing minParallelLength ...

Indicates that floating metal that is greater than or equal to minParSpacing from grounded metal must have greater than or equal to minParallelLength at the minimum spacing distance. If more than one pair of values is given, the smallest spacing value that matches is used. (See Example 2.)
Type: Float, specified in microns (for both values)

The minParSpacing values must be defined in decreasing value, and be smaller than SPACING minSpacing. The intent of the PARSPACING rule is to spread out the charge build up on floating shapes to reduce the chance of spark; therefore, smaller spacing values require larger parallel lengths in order to be legal.

If you define PARSPACING for the same layer more than once (due to overlapping LAYERS layer ranges) the last PARSPACING values overwrite the previous values.

SINGLELAYER minRoutingLayer maxRoutingLayer

Indicates the rule applies to each individual floating metal shape on any routing layer between minRoutingLayer and maxRoutingLayer inclusive. Each shape must have an area that is less than or equal to maxArea, or meet the minimum spacing to other grounded shapes. The names you specify for minRoutingLayer and maxRoutingLayer must be two previously defined LEF routing layers.

SPACING minSpacing

Indicates that if the current layer floating metal has an area that is greater than maxArea, the floating metal on the current layer (and all connected lower layers with CONNECTED or ALLCONNECTED) must be greater than or equal to minSpacing distance from grounded metal for all layers that have MAXFLOATINGAREA rules. If you define SPACING for the same layer more than once (due to overlapping LAYERS layer ranges) the last SPACING value overwrites the previous values.
Type: Float, specified in microns

Maximum Floating Area Rule Examples

Maximum Via Stack Rule

You can create a maximum via stack rule to require a series of stacked vias to all be multi-cut vias. A via is considered to be in a stack with other vias if the cuts of all the vias partially overlap (the boolean AND of the cut layer shapes from every via in the stack is not empty). A multi-cut via interrupts the stack, unless the NOSINGLE keyword is specified.

If multiple MAXVIASTACK statements are defined, all of them must be fulfilled individually.

You can define a maximum via stack rule using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_MAXVIASTACK STRING 
 "MAXVIASTACK maxStack [SAMENET] [NOSINGLE] 
      [IGNOREONESAMEMETAL cutWithin]
      [MINMULTICUT numCut] 
      [WITHIN {LOWCUTSIZE | {cutLayerName within
             [CENTERTOCENTER]}...}
      | CENTERCUTWITHIN cutLayerName
            belowCutWithin aboveCutWithin]
      [EXCEPTPGNET]
      [EXCEPTAREA individualArea sumArea] 
      [RANGE bottomLayer topLayer]
      [EXCEPTCUTCLASSLIST {cutLayer cutClassName}...]
      [[NOVIALIST {viaName}...]...
      |[NOCUTCLASSLIST {cutLayer cutClassName}...]...]
  ;" ;
END PROPERTYDEFINITIONS

Where:

CENTERCUTWITHIN cutLayerName belowCutWithin aboveCutWithin

Specifies that the maximum via stack rule applies only when all of the cuts below a cut on cutLayerName must be within belowCutWithin of that cut and all of the cuts above a cut on cutLayerName must be within aboveCutWithin of that cut. The maximum via stack rule must be defined such that having a cut on cutLayerName is the only way to violate the rule. For example, if a maximum via stack number of 2 is given between six metal layers (and a maximum of five stacked vias in between), CENTERCUTWITHIN cannot be defined on the second cut layer since the upper three vias could violate the rule without a second layer cut. CENTERCUTWITHIN can be defined on the third (middle) cut layer since three or more stacked vias would always have a cut on that layer. See Figure 1-16.
Type: Float, specified in microns

CENTERTOCENTER

Specifies that the within distance between two cuts on adjacent cut layers is measured in the center-to-center style.

EXCEPTAREA individualArea sumArea

Specifies that the rule does not apply if the metal shape containing the stacked vias has an area greater than or equal to individualArea on any layer except the bottommost and topmost metal layers of the stacked vias or the union sum of those metal areas is greater than or equal to sumArea.

If any stacked via larger than the specified maximum number in the rule does not qualify for the exemptions in EXCEPTAREA, it is a violation even if there are additional stacked vias fulfilling the exemption in EXCEPTAREA.

Type: Float, specified in microns squared

EXCEPTCUTCLASSLIST {cutLayer cutClassName}...

Specifies that the rule is exempted for any vias belonging to the given cut class cutClassName on the given layer cutLayer. This means that those vias would interrupt a stack as if the vias did not exist for this max via stack rule.

EXCEPTPGNET

Specifies that the rule is exempted for power or ground net.

IGNOREONESAMEMETAL cutWithin

Specifies that if the cuts within cutWithin have the same metal on at least one metal layer, they are considered multi-cuts, which interrupt the via stack. However, the bottommost stacked via can consider a same-metal cut only on the routing layer above, and the topmost stacked via can consider a same-metal cut only on the routing layer below.

Type: Float, specified in microns

MAXVIASTACK maxStack

Specifies the maximum number of single-cut vias that are allowed on top of each other (that is, in one continuous stack).

Type: Integer

MINMULTICUT numCut

Specifies the minimum multi-cut number to be greater than or equal to numCut in order to be a multi-cut exemption to a stacked via violation with number of vias greater than or equal to maxStack. If NOSINGLE is specified, all of the vias must have a cut number greater than or equal to numCut to pass the rule. By default, without MINMULTICUT, the multi-cut number is 2. Therefore, numCut must be greater than 2.

Type: Integer

[NOCUTCLASSLIST {cutLayer cutClassName}...]...

Specifies that the given cut classes, which belong to the given cutClassName on the given cut layer cutLayer, are not allowed for stacking although the number of cut classes specified in NOCUTCLASSLIST is less than or equal to maxStack.

Type: String

NOSINGLE

Indicates that any single-cut via in a stack that is larger than maxStack is a violation, and multi-cut vias do not interrupt a stack. Therefore, any stack larger than maxStack must consist of all multi-cut vias.

[NOVIALIST {viaName}...]...

Specifies that the given list of vias in {viaName}... is not allowed for stacking although the number of cut vias specified in NOVIALIST is less than or equal to maxStack. The via list should always start from a lowest cut layer and consecutively move up the cut layers, and they should be inside the metal layers in RANGE if defined. Wild card asterisk (*) is supported, which would map to all of the LEF predefined vias that match the wild card. If it is used alone to represent all of the vias on a certain cut layer, the via name on previous or following cut layers would have enough information to indicate what layer the asterisk is referring to.
Type: String

RANGE bottomLayer topLayer

Specifies a range of routing layers for which the maximum stacked via rule applies. If you do not specify a range, the maxStack value applies for all routing layers. The bottomLayer and topLayer values are routing layer names. The specified topLayer layer must be above the layer specified for bottomLayer.

SAMENET

Specifies that the rule applies only to same-net vias.

WITHIN {LOWCUTSIZE | {cutLayerName within}...}

Specifies that an object is considered as a stacked via if the upper adjacent layer cut is within the minimum cut size of multiple CUTCLASS definitions or minWidth value in WIDTH on the lower cut layer in LOWCUTSIZE or within within distance of a cut on the lower layer in cutLayerName. Touching the within search window is considered as stacked.
Type: Float, specified in microns

Maximum Via Stack Rule Examples

Metal Width Track Rule

You can create a metal width track rule to define the preferred routing direction for tracks on a specified layer.

You can define a metal width track rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_METALWIDTHTRACK STRING
“METALWIDTHTRACK routingLayer COREOFFSET offset
{WIDTH width PITCH pitch [REPEAT repeat]}...
;” ;
END PROPERTYDEFINITIONS

Where:

METALWIDTHTRACK routingLayer COREOFFSET offset
{WIDTH width PITCH pitch [REPEAT repeat]}...

Specifies the preferred routing direction tracks on the layer routingLayer. offset specifies the starting coordinate of the track with respect to the origin of the core. The width and pitch set of values define the width and pitch of the subsequent tracks. repeat specifies how many times the given width and pitch should be repeated. Then, the entire sets of width and pitch would be repeated. Multiple METALWIDTHTRACK statements can be defined for different routing layers. For example:

METALWIDTHTRACK M1 ...
METALWIDTHTRACK M2 ...

However, one routing layer can have only one such statement. So, it would be illegal to have the following:

METALWIDTHTRACK M1 ...
METALWIDTHTRACK M1 ...

The METALWIDTHTRACK property is typically used to define a non-uniform track on a certain layer, which depend on the cell objects on the corresponding layer. In advanced nodes, all of the cell objects are typically required on the track on lower layers. Horizontal, non-uniform tracks may be created such that instances could be placed on any row such that the cell objects are still ensured on the track. Therefore, this library property is likely to be defined in a cell LEF or side LEF file, instead of in a tech LEF file.
Type: Float, specified in microns

Metal Width Track Rule Example

Metal Width Via Map Rule

You can create a metal width via map rule to specify the vias to be used based on the given width values of the below and above metal layers.

You can define a metal width via map rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_METALWIDTHVIAMAP STRING
   "METALWIDTHVIAMAP
       [USEVIACUTCLASS]
       {VIA viaLayer 
          {belowLayerWidth aboveLayerWidth 
          |belowLayerLowWidth belowLayerHighWidth 
             aboveLayerLowWidth aboveLayerHighWidth} 
          viaName [PGVIA]}...
       ;..." ;
END PROPERTYDEFINITIONS

Where:

METALWIDTHVIAMAP {VIA viaLayer belowLayerWidth aboveLayerWidth viaName}...

Specifies the vias to be used based on the given width values of the below and above metal layers. viaName is used on cut layer viaLayer for below and above metal widths of belowLayerWidth and aboveLayerWidth. When multiple vias are defined for the same below and above metal width combination, the first defined via is preferred. When a DRC violation occurs, other defined vias are attempted.

Type: Float, specified in microns

PGVIA

Specifies that the given via is for PG net usage only. For a given below and above metal width combination, you can do one of the following:

  • Define only one via to be used for both signal and PG nets. This via should be defined without PGVIA.
  • Define multiple vias of which one is without PGVIA. In this case, the via without PGVIA would be used for signal nets, and the rest of the vias with PGVIA would be used for PG nets.

USEVIACUTCLASS

Indicates that viaName is actually a cut class name on the given layer, viaLayer. Any cuts belonging to the given cut class could be used on the given width combination.

For example,

LIBRARY LEF58_ METALWIDTHVIAMAP STRING "
METALWIDTHVIAMAP USEVIACUTCLASS
VIA V1 0.05 0.08 V1_CUTCLASSA ; " ;
END PROPERTYDEFINITIONS

means that any V1 cuts belonging to cut class V1_CUTCLASSA could be used for nets on below metal width of 0.05 and above metal width of 0.08 wires.

VIA viaLayer belowLayerLowWidth belowLayerHighWidth 
   aboveLayerLowWidth aboveLayerHighWidth viaName...

Specifies the vias to be used based on the given width range values of the below and above metal layers. That is the below and above metal width should be greater than or equal to belowLayerLowWidth and aboveLayerLowWidth, respectively, and less than or equal to belowLayerHighWidth and aboveLayerHighWidth, respectively, to use viaName.

Type: Float, specified in microns

Metal Width Via Map Rule Examples

OpenAccess Layer Map Rule

You can create an OpenAccess layer map rule to define equivalence between LEF and OpenAccess layers and also between the geometries and shapes placed on the layers.

You can define an OpenAccess layer map rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_OALAYERMAP STRING
“OALAYERMAP oaLayer
{ [PURPOSE oaPurpose] BLOCKAGE layer
| LAYER layer [MASK maskNum] }
;...” ;
END PROPERTYDEFINITIONS

Here, LEF58_OALAYERMAP can contain multiple mapping statements, separated by ‘;’. The property syntax allows two variants of the statement:

OALAYERMAP oaLayer LAYER layer [MASK maskNum]

Specifies the equivalent OpenAccess layer name oaLayer for the LEF layer layer and also specifies the mapping between the shapes placed on the layers. If the MASK keyword is specified (allowed only for LEF multi-patterning layers with a MASK statement), the mapping will be mask-based; that is, the color mask maskNum of the LEF layer layer is mapped to the OpenAccess layer oaLayer and the LEF layer shapes with the color mask are converted into the OpenAccess layer shapes.

Note: Typically, mask-based mapping requires multiple OALAYERMAP statements per LEF layer, with one statement for each possible color mask.

Type: String

OALAYERMAP oaLayer [PURPOSE oaPurpose] BLOCKAGE layer

Maps the LEF/DEF blockage-type geometries on the LEF layer layer to regular shapes on the OpenAccess layer oaLayer. These blockage-type geometries are represented as LEF OBS statement geometries in the LEF file and DEF BLOCKAGES statement geometries in the DEF file.

If the PURPOSE keyword is specified in the statement, the OpenAccess shapes are set to the oaPurpose purpose in the conversion. Otherwise, they are set to the default drawing purpose.

Note: This variant of the OALAYERMAP statement does not specify the mapping between LEF and OpenAccess layers.

Type: String

OpenAccess Layer Map Rule Examples

PG Via Track Rule

You can use a PG via track rule to define vertical tracks for aligning all of the power and ground cell vias on a specified layer of a cell macro with the ALIGNPGVIATOTRACK property.

You can define a PG via track rule by using the the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_PGVIATRACK STRING
“PGVIATRACK cutLayer COREOFFSET offset PITCH pitch; “ ;
END PROPERTYDEFINITIONS

Where:

PGVIATRACK cutLayer COREOFFSET offset PITCH pitch

Defines vertical tracks for aligning all the power and ground cell vias on the layer cutLayer of a cell macro with the ALIGNPGVIATOTRACK property. offset specifies the starting coordinate of the track with respect to the origin of the core. pitch specifies the pitch of the tracks. All the power and ground cell vias should be in multiples of pitch such that aligning any one of them to the track is sufficient.
Type: Float, specified in microns

PG Via Track Rule Example

The following example is an illustration of the PG via track rule:

PROPERTYDEFINITIONS
LIBRARY LEF58_PGVIATRACK STRING “
PGVIATRACK VIA1 COREOFFSET 0.15
PITCH 0.2 ; “ ;
END PROPERTYDEFINITIONS

Figure 1-20 Illustration of the PG Via Track Rule

Stack Via Layer Rule

You can use a stack via layer rule to define stack via rules on individual layers. These rules are combined to form a stack via rule.

You can define a stack via layer rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_STACKVIALAYERRULE STRING
“STACKVIALAYERRULE ruleName
LAYER cutLayerName [CUTCLASS className]
ROWCOL numCutRows numCutCols
[XPITCH xPitch [MAXXPITCH maxXPitch]]
[YPITCH yPitch [MAXYPITCH maxYPitch]]
[BELOWMINLENGTH belowMinLength]
[ABOVEMINLENGTH aboveMinLength]
[MAXCELLEXTENSION extensionPitch]
[OFFGRIDCUT]
[MAXXLINEEND maxLeftExtensiion maxRightExtension]
[MAXYLINEEND maxBottomExtensiion maxTopExtension]
; “ ;
END PROPERTYDEFINITIONS

Where:

ABOVEMINLENGTH aboveMinLength

Specifies the minimum length of the default width wires on the above metal layer. This construct must be specified with XPITCH and/or YPITCH.
Type: Float, specified in microns

BELOWMINLENGTH belowMinLength

Specifies the minimum length of the default width wires on the below metal layer. This construct must be specified with XPITCH and/or YPITCH.
Type: Float, specified in microns

MAXCELLEXTENSION extensionPitch

Specifies the maximum number of pitch extensionPitch extended from the cell boundary of the pin along both directions from which the stacked vias must be enclosed. By default, the stacked vias must be inside the cell boundary if this construct is not specified.
Type: Integer

MAXXLINEEND maxLeftExtensiion maxRightExtension

Forms a boundary box of the pin shapes to which the stacked vias connect and expands to the left and right horizontally by maxLeftExtension and maxRightExtension, respectively. All of the via cuts on this layer must be enclosed by this expanded boundary box. If negative values are given, it would shrink the boundary box in the given direction. This construct should be mutually exclusive to MAXCELLEXTENSION.

Type: Float, specified in microns

MAXXPITCH maxXPitch

Specifies the maximum number of pitch by which all the vertical minimum-default-width metal wires of the stacked vias could be apart. The pitch must be smaller than or equal to the given value.
Type: Integer

MAXYLINEEND maxBottomExtensiion maxTopExtension

Forms a boundary box of the pin shapes to which the stacked vias connect and expands to the bottom and top vertically by maxBottomExtension and maxTopExtension, respectively. All of the via cuts on this layer must be enclosed by this expanded boundary box. If negative values are given, it would shrink the boundary box in the given direction. This construct should be mutually exclusive to MAXCELLEXTENSION.

Type: Float, specified in microns

MAXYPITCH maxYPitch

Specifies the maximum number of pitch by which all the horizontal minimum-default-width metal wires of the stacked vias could be apart. The pitch must be smaller than or equal to the given value.
Type: Integer

OFFGRIDCUT

Specifies that the cuts could be placed off grid to block fewer routing and the below metal shape would become an L shape. It is typically applied on a transition cut layer in which the cut size is larger than the default wire width on the below metal.

STACKVIALAYERRULE ruleName
LAYER cutLayerName [CUTCLASS className]
ROWCOL numCutRows numCutCols

Specifies a stacked via rule on cut layer cutLayerName with className cuts. If CUTCLASS is not specified, the cut class with the smallest cut size would be used or the table lookup cut class would be applied based on the wire width if METALWIDTHVIAMAP is defined. These stacked via rules would be combined in STACKVIARULE to build stacked vias on top of some special instance pins. ROWCOL specifies the number of cut rows and columns of a multiple-cuts via of cut class className to use on the pin.
Type: String and Integer
Note that this rule is only for via creation. It is difficult to re-determine the cut dimension of a generated via, and the checker does not check for the correctness of the generated vias.

XPITCH xPitch

Specifies that all the individual cuts must be on the grid on both the top and bottom metal layers. The cuts are xPitch horizontally. There would be multiple vertical minimum-default-width metal wires, and each one of them would connect separately to a cut. In the case of a transition cut layer, the cut size would be larger than the default wire width on the below metal layer. It is typical to apply the OFFGRIDCUT construct such that the below metal shape becomes an L shape to block fewer tracks. If the common metal between two adjacent cut layers is vertical, xPitch on these two cut layers must be identical if they are defined. If neither XPITCH nor YPITCH is specified, the tool would automatically determine the proper pitch values. If zero is given in both of the pitches, a typical via with one large metal shape each on both the top and bottom layers would be created.
Type: Integer

YPITCH yPitch

Specifies that all the individual cuts must be on the grid on both the top and bottom metal layers. The cuts are yPitch vertically. There would be multiple horizontal minimum-default-width metal wires, and each one of them would connect separately to a cut. In the case of a transition cut layer, the cut size would be larger than the default wire width on the below metal layer. It is typical to apply the OFFGRIDCUT construct such that the below metal shape becomes an L shape to block fewer tracks. If the common metal between two adjacent cut layers is horizontal, yPitch on these two cut layers must be identical if they are defined. If neither XPITCH nor YPITCH is specified, the tool would automatically determine the proper pitch values. If zero is given in both of the pitches, a typical via with one large metal shape each on both the top and bottom layers would be created.
Type: Integer

Stack Via Layer Rule Examples

Stack Via Rule

You can create a stack via rule to specify a list of stack via rules for individual layers.

You can define a stack via rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_STACKVIARULE STRING
“STACKVIARULE ruleName {stackLayerRuleName}...[EMFACTOR emFactor]
; “ ;
END PROPERTYDEFINITIONS

Where:

EMFACTOR emFactor

Specifies an EM-effective factor to indicate how well this stack via rule could prevent EM violations. The higher the specified number, the more effective is the rule in preventing EM violations.

Type: Float

STACKVIARULE ruleName {stackLayerRuleName}...

Specifies a stacked via rule, which consists of a list of stack via rules on individual layers in the given stackLayerRuleName. This list of stack via rules are the rule names specified with STACKVIALAYERRULE. stackLayerRuleName should correspond to individual layer rules on consecutive layers. It is illegal to define multiple stackLayerRuleName on the same layer. STACKVIALAYERRULE statements should be defined prior to STACKVIARULE in the tech LEF file.
Type: String

Tap Distance Rule

You can create a tap distance rule to specify distance between well tap cells.

You can define a tap distance rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_TAPDISTANCE STRING
“TAPDISTANCE {distance | TAPDISTANCERULE ruleName
|{HALFROW rowNum [LEFT|RIGHT]
   {distance | TAPDISTANCERULE ruleName}}...}
TAPTYPE typeName
; “ ;
END PROPERTYDEFINITIONS

Where:

TAPDISTANCE {distance | TAPDISTANCERULE ruleName
|{HALFROW rowNum [LEFT|RIGHT]
{distance | TAPDISTANCERULE ruleName}}...}
   TAPTYPE typeName

Specifies that the effective distance of a well tap cell with type typeName should be distance on both the left and right sides of the cell, which the cell could cover. If TAPDISTANCERULE is specified, the distance is obtained from the tap distance rule ruleName. The distance is measured from the center of the cell. For example, the center-to-center distance between two well tap cells of the same type must be less than or equal to 2 * distance.

Type: Float, specified in microns

HALFROW specifies that different distances could be defined on a half row basis, either in distance or in the distance defined in the tap distance rule ruleName. rowNum specifies the half row, with respect to the cell origin, on which the distance is defined.

LEFT|RIGHT specifies that different distances could be defined on the left or right sides on a half cell row basis. Left and right is referred with respect to the cell origin.

Tap Distance Rule Example

Tap Distance Rule Property

You can create a tap distance rule property to specify effective tap distance.

You can define a tap distance rule property by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_TAPDISTANCERULE STRING
“TAPDISTANCERULE ruleName DEFAULT distance
[LAYER layerName layerDistance]...
     ; ”;
END PROPERTYDEFINITIONS

Where:

TAPDISTANCERULE ruleName DEFAULT distance
[LAYER layerName layerDistance]...

Specifies that a rule with the name ruleName has an effective tap distance of distance by default and layerDistance when a tap cell overlaps with the areas on the layer layerName, which should be a WELLDISTANCE masterslice layer. The TAPDISTANCE library property could refer to this tap distance rule to determine the effective tap distance.

Type: Float, specified in microns

Trim Metal Track Rule

You can create a trim metal track rule to define the trim metal tracks on a trim layer.

You can define a trim metal track rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_TRIMMETALTRACK STRING
“TRIMMETALTRACK trimLayer [GROUP groupName]
     [ONTRACK [HALFINFILLER | HALFNONMERGED]
         [INCLUDELINEEND [TRIMCENTER]]]
     [MASK maskNum
     |METALTRACKOFFSET trackNumber METALTRACKPITCH trackPitch] 
     COREOFFSET offset PITCH pitch
     ;” ;
END PROPERTYDEFINITIONS

Where:

GROUP groupName

Assigns a group name to the track definition. If any one of the TRIMMETALTRACK statements has GROUP, GROUP must be specified on all of the TRIMMETALTRACK statements. A separate command is used to define which group of TRIMMETALTRACK statements would be applied on a design.

Type: String

HALFNONMERGED

Specifies that any non-merged trims could be on the half track as an exemption.

INCLUDELINEEND

Specifies that the line-end edges with default wire width or width lesser than or equal to the width value in EXCEPTWIDTH in the corresponding TRIMSHAPE definition if specified without a trim should also snap to the given hard trim grid. In other words, if a trim were to be added on that line-end edge, that imaginary trim should be on-grid.

METALTRACKOFFSET trackNumber METALTRACKPITCH trackPitch

Specifies that the trim metal track is applied on the trackNumber metal track with respect to the core and all the tracks that are apart by a multiple of trackPitch track. If METALTRACKPITCH is defined on a certain given layer, all the other trim metal track statements on that layer must have METALTRACKPITCH with the same value. In addition, there should be at least pitch number of those statements. They should have different trackNumber statements and together they cover the track number of 1 to trackPitch. Then, multiple statements with the same trackNumber but with different offset could be defined.

Type: Integer

ONTRACK [HALFINFILLER]

Specifies the trim metal tracks are a hard constraint. It means that all of the inserted trims must be on a track and having an off-grid trim would be a violation by itself. HALFINFILLER means that trims on some special 1CPP filler cells could be on the half track as an exemption. The tool has a separate option to identify those special cells. This hard constraint does not apply to pre-defined trims in MACRO in the cell LEF. In addition, if one TRIMMETALTRACK statement defines ONTRACK on a trimLayer, all of the statements on that trim layer must also have ONTRACK.

TRIMCENTER

Specifies that line-end edges with default wire width or width lesser than or equal to the width value in EXCEPTWIDTH in the corresponding TRIMSHAPE definition if specified without a trim should snap to the center of the trim grid.

TRIMMETALTRACK trimLayer [MASK maskNum] COREOFFSET offset
PITCH pitch

Specifies the trim metal tracks on layer trimLayer. The direction of the tracks should always be the orthogonal direction of the preferred routing direction of the metal layer defined in TRIMMEDMETAL on the layer trimLayer that the trim metal trims.
maskNum defines the metal track mask on which the trim grids are applied.
offset specifies the starting coordinate of the track with respect to the origin of the core with repeatable tracks that are pitch apart. Multiple statements could be defined on the same mask and/or different masks for different sets of tracks. Typically, the trim metal tracks depend on the cell objects, and this library property is likely to be defined in a cell LEF or side LEF file, instead of in a tech LEF file.

Type: Float, specified in microns

Trim Metal Track Rule Examples

Voltage Mode Rule

You can create a voltage mode rule to define how voltage should be computed in VOLTAGESPACING spacing.

You can define a voltage mode rule by using the following PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
LIBRARY LEF58_VOLTAGEMODE STRING
“VOLTAGEMODE ABSOLUTE
; “ ;
END PROPERTYDEFINITIONS

Where:

VOLTAGEMODE ABSOLUTE

Specifies that the absolute maximum voltage of a net is used to define which VOLTAGESPACING spacing value should be applied on that net. The voltage of neighboring nets is irrelevant.

Macro

MACRO macroName
[CLASS 
  { COVER [BUMP]
  | RING 
  | BLOCK [BLACKBOX | SOFT]
  | PAD [INPUT | OUTPUT |INOUT | POWER | SPACER | AREAIO]
  | CORE [FEEDTHRU | TIEHIGH | TIELOW | SPACER | ANTENNACELL | WELLTAP]
  | ENDCAP {PRE | POST | TOPLEFT | TOPRIGHT | BOTTOMLEFT | BOTTOMRIGHT} 
  } 
;]
[FIXEDMASK ;]
[FOREIGN foreignCellName [pt [orient]] ;] ... 
[ORIGIN pt ;]
[EEQ macroName ;]
[SIZE width BY height ;]
[SYMMETRY {X | Y | R90} ... ;]
[SITE siteName [sitePattern] ;] ...
[PIN statement] ...
[OBS statement] ...
[DENSITY statement] ...
[PROPERTY propName propVal ;] ...
[PROPERTY LEF58_ACCESSAREA
   "ACCESSAREA {LAYER layerName RECT pt pt [CUTCLASS className]
   [EXCEPTEXTRACUT]}...
   ; " ;]
[PROPERTY LEF58_ALIGNPGVIATOTRACK
   "ALIGNPGVIATOTRACK
   ; " ;]
[PROPERTY LEF58_ALLPINSCONNECTED
   "ALLPINSCONNECTED
   ; " ;]
[PROPERTY LEF58_CLASS
  "CLASS 
    {COVER [BUMP | FILL]
    | RING
    | BLOCK [BLACKBOX | SOFT]
    | PAD [INPUT | OUTPUT | INOUT | POWER | SPACER | AREAIO]
    | CORE [FEEDTHRU | TIEHIGH | TIELOW | SPACER 
          | ANTENNACELL | WELLTAP [TAPWALL] [TAPTYPE typeName]]
    | ENDCAP {PRE | POST | TOPLEFT | TOPRIGHT | BOTTOMLEFT
              | BOTTOMRIGHT
              | TOPEDGE | BOTTOMEDGE | LEFTEDGE | RIGHTEDGE  
              | LEFTEVENSITEEDGE | LEFTODDSITEEDGE
              | RIGHTEVENSITEEDGE | RIGHTODDSITEEDGE
              | LEFTTOPEDGE | RIGHTTOPEDGE 
              | LEFTBOTTOMEDGE | RIGHTBOTTOMEDGE
              | LEFTTOPEVENSITEEDGE | LEFTTOPODDSITEEDGE
              | RIGHTTOPEVENSITEEDGE | RIGHTTOPODDSITEEDGE
              | LEFTBOTTOMEVENSITEEDGE 
              | LEFTBOTTOMODDSITEEDGE
              | RIGHTBOTTOMEVENSITEEDGE 
              | RIGHTBOTTOMODDSITEEDGE
              | LEFTTOPCORNER | RIGHTTOPCORNER 
              | LEFTBOTTOMCORNER | RIGHTBOTTOMCORNER
              | LEFTTOPEVENSITECORNER | LEFTTOPODDSITECORNER
              | RIGHTTOPEVENSITECORNER 
              | RIGHTTOPODDSITECORNER
              | LEFTBOTTOMEVENSITECORNER
              | LEFTBOTTOMODDSITECORNER
              | RIGHTBOTTOMEVENSITECORNER 
              | RIGHTBOTTOMODDSITECORNER
              | LEFTEDGETOPBORDER
              | LEFTEDGEBOTTOMBORDER
              | RIGHTEDGETOPBORDER
              | RIGHTEDGEBOTTOMBORDER
              | LEFTTOPEDGENEIGHBOR
              | RIGHTTOPEDGENEIGHBOR
              | LEFTBOTTOMEDGENEIGHBOR
              | RIGHTBOTTOMEDGENEIGHBOR
              | LEFTTOPCORNERNEIGHBOR 
              | RIGHTTOPCORNERNEIGHBOR 
              | LEFTBOTTOMCORNERNEIGHBOR 
              | RIGHTBOTTOMCORNERNEIGHBOR 
              | LEFTCORNERTOPBORDER
              | RIGHTCORNERTOPBORDER
              | LEFTCORNERBOTTOMBORDER
              | RIGHTCORNERBOTTOMBORDER
              | TOPCORNEREDGENEIGHBOR
              | BOTTOMCORNEREDGENEIGHBOR
              | TSVTOPEDGE | TSVBOTTOMEDGE
              | TSVLEFTEDGE | TSVRIGHTEDGE
              | TSVLEFTTOPCORNER | TSVLEFTBOTTOMCORNER
              | TSVRIGHTTOPCORNER | TSVRIGHTBOTTOMCORNER
              | TSVLEFTTOPEDGE | TSVLEFTBOTTOMEDGE
              | TSVRIGHTTOPEDGE | TSVRIGHTBOTTOMEDGE
              | TSVLEFTTOPEDGENEIGHBOR
              | TSVRIGHTTOPEDGENEIGHBOR
              | TSVLEFTBOTTOMEDGENEIGHBOR
              | TSVRIGHTBOTTOMEDGENEIGHBOR
              | TSVLEFTTOPCORNERNEIGHBOR
              | TSVRIGHTTOPCORNERNEIGHBOR
              | TSVLEFTBOTTOMCORNERNEIGHBOR
              | TSVRIGHTBOTTOMCORNERNEIGHBOR}
              [TAPWALL] [TAPTYPE typeName]
}
    }
  ; " ;]
[PROPERTY LEF58_CONSTRAINTAREATYPE
   "CONSTRAINTAREATYPE typeName {RECT pt pt}...
    ;..." ;]
[PROPERTY LEF58_EDGETYPE
   "EDGETYPE {RIGHT | LEFT | TOP | BOTTOM}
    edgeType | BOTHSOURCE | SOURCEDRAIN | DRAINSOURCE | BOTHDRAIN 
    | BOTHFLOATING
    [CELLROW cellRow  | HALFROW halfRow | RANGE xLow xHigh]
    ;..." ;]
[PROPERTY LEF58_EEQ
   "EEQ macroName [VARIANT num]
    ;... " ;]
[PROPERTY LEF58_FOREIGN
   "FOREIGN foreignCellName [pt [orient]] 
         [COMPORIENT foreignOrientName {compOrient}...]...
    ;... " ;]
[PROPERTY LEF58_LAYERMASKSHIFT
   "LAYERMASKSHIFT layer1 [layer2 ...] 
    ;... " ;]
[PROPERTY LEF58_OBSPARTIAL
  "OBSPARTIAL {LAYER layerName 
    WIDTH width SPACING spacing RECT pt pt}...
  ; " ;]
[PROPERTY LEF58_OBSSPACING
  "OBSSPACING {FULLDRC | MIN | spacing} [LAYER layerName]...
  ; " ;]
[PROPERTY LEF58_PLACEWITHIN
  "PLACEWITHIN within PRL prl {WITH|WITHOUT} LAYER {layerName}...
  ; " ;]
[PROPERTY LEF58_REQ
   "REQ macroName 
    ; " ;]
[PROPERTY LEF58_TAPCENTEROFFSET
  "TAPCENTEROFFSET
    {offset | {HALFROW rowNum [LEFT|RIGHT] offset}...}
  ; " ;]
END macroName 

Defines macros in the design.

Note: The keywords must be specified in the given order. For example if ORIGIN and SITE are both defined, ORIGIN must be specified first.

CLASS

Specifies the macro type. If you do not specify CLASS, the macro is considered a CORE macro, and a warning prints when the LEF file is read in. You can specify macros of the following types:

COVER

Macro with data that is fixed to the floorplan and cannot change, such as power routing (ring pins) around the core. The placers understand that CLASS COVER cells have no active devices (such as diffusion or polysilicon), so the MACRO SIZE statement does not affect the placers, and you do not need an artificial OVERLAP layer. However, any pin or obstruction geometry in the COVER cells can affect the pin access checks done by the placers.

A cover macro can be of the following sub-class:

BUMP—A physical-only cell that has bump geometries and pins. Typically a bump cell has geometries only on the top-most “bump” metal layer, although it might contain a via and pin to the metal layer below.

RING

Large macro that has an internal power mesh, and only exposes power-pin shapes that form a ring along the macro boundary. When power stripes are added across the macro, they connect to each side of the ring-pin but do not go inside the ring. The CLASS RING macro can also be used for power-switch cells that are abutted together to form a power-ring around a power-domain. In that case, their power-pins have the same effect of interrupting power stripes as the ring-pins in a single block RING macro.

BLOCK

Predefined macro used in hierarchical design.

A block macro can have one of the following sub-classes:

BLACKBOX—A block that sometimes only contains a SIZE statement that estimates its total area. A blackbox can optionally contain pins, but in many cases, the pin names are taken from a Verilog description and do not need to match the LEF MACRO pin names.

SOFT—A cell that also contains a version of the sub-block that is not fully implemented. Normally, a soft block LEF can still have certain parts of it modified (for example, the aspect ratio, or pin locations) because the sub-block is not yet fully implemented. Any changes should be passed to the sub-block implementation. In contrast, a BLACKBOX has no sub-block implementation available.

PAD

I/O pad. A pad can be one of the following types: INPUT, OUTPUT, INOUT, POWER, or SPACER, for I/O rows; INPUT, OUTPUT, INOUT, or POWER, for I/O corner pads; AREAIO for area I/O driver cells that do not have the bump built in as part of the macro (and therefore require routing to a CLASS COVER BUMP macro for a connection to the IC package).
Note: Unlike CORE SPACER, PAD SPACER can contain logic pins.

For an example of a macro pad cell, see Example 1-2.

CORE

A standard cell used in the core area. CORE macros should always contain a SITE definition so that standard cell placers can correctly align the CORE macro to the standard cell rows.

A core macro can be one of the following types:

FEEDTHRU—Used for connecting to another cell.

TIEHIGH,TIELOW—Used for connecting unused I/O terminals to the power or ground bus. The software does not rely on this sub-class.  A tie-cell has to be CLASS CORE, but the software does not consider the sub-class to determine its type. The dotlib representation of the cell's output pin is considered, and based on the function on that pin, it is determined whether it is a tiehigh, or tielow.

SPACER—Sometimes called a filler cell, this cell is used to fill in space between regular core cells. The SPACER sub-class needs to be cells with no logic-pins. Thus even with the sub-class defined, a cell will not be considered SPACER (also called FILLER) unless it has no logic/signal pins. A filler can only have Power and Ground pins. The instances of these cells will be marked by the insertion command to be of type 'Physical'.

ANTENNACELL—Used for solving process antenna violations. This cell has a single input to a diode to bleed off charge that builds up during manufacturing.

WELLTAP—Standard cell that connects N and P diffusion wells to the correct power or ground wire. The WELLTAP cells provide a tap for the N and P wells to the power/ground wires.

ENDCAP

A macro placed at the ends of core rows (to connect with power wiring).

If the library includes only one corner I/O macro, then appropriate SYMMETRY must be included in its macro description. An ENDCAP macro can be one of the following types:
PRE—A left-end macro
POST—A right-end macro
TOPLEFT—A top left I/O corner cell
TOPRIGHT—A top right I/O corner cell
BOTTOMLEFT —A bottom left I/O corner cell
BOTTOMRIGHT—A bottom right I/O corner cell

The ENDCAP sub-class is required. The PRE and POST are CORE area cells, whereas the other four are PAD CLASS.  

Example 1-2 Macro Pad Cell

The following example defines a power pad cell that illustrates when to use the CLASS CORE keywords on power ports. For the VDD pin, there are two ports: one to connect to the interior core power ring, and one to complete the I/O power ring. Figure 1-26 illustrates this pad cell.

MACRO PAD_0
CLASS PAD ;
FOREIGN PAD_0 0.000 0.000 ;
ORIGIN 0.000 0.000 ;
SIZE 100.000 BY 300.000 ;
SYMMETRY X Y R90 ;
SITE PAD_SITE ; 
# Define pin VDD with SHAPE ABUTMENT because there are no obstructions
# to block a straight connection to the pad rings. The port without
# CLASS CORE is used for completing the I/O power ring.
PIN VDD
DIRECTION INOUT ;
USE POWER ;
SHAPE ABUTMENT ;
PORT 
   LAYER metal2 ;
     RECT 0.000 250.000 100.000 260.000 ;
   LAYER metal3 ;
     RECT 0.000 250.000 100.000 260.000 ;
END
# Define VDD port with PORT CLASS CORE to indicate that the port connects 
# to the core area instead of to the pad ring.
  PORT 
   CLASS CORE ;
   LAYER metal2 ;
     RECT 0.000 290.000 100.000 300.000 ;
   LAYER metal3 ;
     RECT 0.000 290.000 100.000 300.000 ;
  END
END VDD
# Define pins VCC and GND with SHAPE FEEDTHRU because these pins 
# cannot make a straight connection to the pad rings due to obstructions.
PIN VCC 
  DIRECTION INOUT ;
  USE POWER ;
  SHAPE FEEDTHRU ;
  PORT
    LAYER metal2 ;
      RECT 0.000 150.000 20.000 160.000 ;
      RECT 20.000 145.000 80.000 155.000 ;
      RECT 80.000 150.000 100.000 160.000 ;
    LAYER metal3 ;
      RECT 0.000 150.000 20.000 160.000 ;
      RECT 20.000 145.000 80.000 155.000 ;
      RECT 80.000 150.000 100.000 160.000 ;
  END
END VCC
PIN GND
DIRECTION INOUT ;
USE GROUND ;
SHAPE FEEDTHRU ;
PORT
   LAYER metal2 ;
     RECT 0.000 50.000 20.000 60.000 ;
     RECT 80.000 50.000 100.000 60.000 ;
END
END GND
OBS 
LAYER metal1 ;
    RECT 0.000 0.000 100.000 300.000 ;
LAYER metal2 ;
    RECT 25.000 50.000 75.000 60.000 ;
    RECT 30.500 157.000 70.500167.000 ;
END
END PAD_0

Figure 1-27 Power Pad Cell

DENSITY statement

Specifies the metal density for large macros.

The DENSITY rectangles on a layer should not overlap, and should cover the entire area of the macro. You can choose the size of the rectangles based on the uniformity of the density of the block. If the density is uniform, a single rectangle can be used. If the density is not very uniform, the size of the rectangles can be specified to be 10 to 20 percent of the density window size, so that any error due to non-uniform density inside each rectangle area is small.

For example, if the metal density rule is for a 100 μm x 100 μm window, the density rectangles can be 10x10 μm squares. Any non-uniformity will have little impact on the density calculation accuracy.

If two adjacent rectangles have the same or similar density, they can be merged into one larger rectangle, with one average density value. The choice between accuracy and abstraction is left to the abstract generator.

The DENSITY syntax is defined as follows:

[DENSITY {LAYER layerName ; {RECT x1 y1 x2 y2 densityValue ;} ... } ... END] ...

densityValue

Specifies the density for the rectangle, as a percentage. For example, 50.0 indicates that the rectangle has a density of 50 percent on layerName.
Type: Float
Value: 0 to 100

layerName

Specifies the layer on which to create the rectangle.

x1 y1 x2 y2

Specifies the coordinates of a rectangle.
Type: Float, specified in microns

Example 1-3 Macro Density

The following statement specifies the density for macro testMacro:

MACRO testMacro 
CLASS ...
PIN ...
OBS ...
DENSITY
LAYER metal1 ;
RECT 0 0 100 100 45.5 ; #rect from (0,0) to (100,100), density of 45.5%
RECT 100 0 200 100 42.2 ; #rect from (100,0) to (200, 100), density of 42.2%
END
...
END testMacro

EEQ macroName

Specifies that the macro being defined should be electrically equivalent to the previously defined macroName. EEQ macros include devices such as OR-gates or inverters that have several implementations with different shapes, geometries, and orientations.
Electrically equivalent macros have the following requirements:

FIXEDMASK

Indicates that the specified macro does not allow mask-shifting. All the LEF PIN MASK assignments must be kept fixed and cannot be shifted to a different mask to optimize routing density.  All the LEF PIN shapes should have MASK assignments, if FIXEDMASK statement is present.

For example,

MACRO my_block
CLASS BLOCK ;
FIXEDMASK ;
...

FOREIGN foreignCellName [pt [orient]]

Specifies the foreign (GDSII) structure name to use when placing an instance of the macro. The optional pt coordinate specifies the macro origin (lower left corner when the macro is in north orientation) offset from the foreign origin. The FOREIGN statement has a default offset value of 0 0, if pt is not specified.

The optional orient value specifies the orientation of the foreign cell when the macro is in north orientation. The default orient value is N (North).

Example 1-4 Foreign Statements

The following examples show two variations of the FOREIGN statement. The negative offset specifies that the GDSII structure should be above and to the right of the macro lower left corner.

MACRO ABC ...
FOREIGN ABC -2 -3 ; 

The positive offset specifies that the GDSII structure should be below and to the left of the macro lower left corner.

MACRO EFG ...
FOREIGN EFG 2 3 ;

MACRO macroName

Specifies the name of the library macro.

OBS statement

Defines obstructions on the macro. Obstruction geometries are specified using layer geometries syntax. See “Macro Obstruction Statement” for syntax information.

ORIGIN pt

Specifies how to find the origin of the macro to align with a DEF COMPONENT placement point. If there is no ORIGIN statement, the DEF placement point for a North-oriented macro is aligned with 0, 0 in the macro. If ORIGIN is given in the macro, the macro is shifted by the ORIGIN x, y values first, before aligning with the DEF placement point. For example, if the ORIGIN is 0, -1, then macro geometry at 0, 1 are shifted to 0, 0, and then aligned to the DEF placement point.

PIN statement

Defines pins for the macro. See “Macro Pin Statement” for syntax information.

PROPERTY propName propVal

Specifies a numerical or string value for a macro property defined in the PROPERTYDEFINITIONS statement. The propName you specify must match the propName listed in the PROPERTYDEFINITIONS statement.

SITE siteName [sitePattern]

Specifies the site associated with the macro. Normal row-based standard cells only have a single SITE siteName statement, without a sitePattern. The sitePattern syntax indicates that the cell is a gate-array cell, rather than a row-based standard cell. Gate-array standard cells can have multiple SITE statements, each with a sitePattern.

The sitePattern syntax is defined as follows:

[xOrigin yOrigin siteOrient [stepPattern]]

Where:

xOrigin yOrigin

Specifies the origin of the site inside the macro.
Type: Float, specified in microns

siteOrient

Specifies the orientation of the site at that location.
Value: N, S, E, W, FN, FS, FE, or FW

Legal placement locations for macros with site patterns must match the site pattern inside the macro to the site pattern in the design rows.

If the site is repeated, you can specify a stepPattern that defines the repeating pattern. The stepPattern syntax is defined as follows:

[DO xCount BY yCount STEP xStep yStep]

xCount yCount

Specifies the number of sites to add in the x and y directions. You must specify values that are greater than or equal to 0 (zero).
Type: Integer

xStep yStep

Specifies the spacing between sites in the x and y directions.
Type: Float, specified in microns

Example 1-5 Macro Site

The following statement defines a macro that uses the sites created in Example 1-17:

MACRO myTest 
CLASS CORE ;
SIZE 10.0 BY 14.0 ;   #Uses 2 F and 1 L site, is F + L wide, and double height
SYMMETRY X ;          #Can flip about the X axis
SITE Fsite 0 0 N ;    #The lower left Fsite at 0,0
SITE Fsite 0 7.0 FS ; #The flipped south Fsite above the first Fsite at 0,7
SITE Lsite 4.0 0 N ;  #The Lsite to the right of the first Fsite at 4,0
...
PIN ... ;
END myTest 

Figure 1-27 illustrates the placement results of this definition.

Figure 1-28

The following statement includes the gate-array site pattern syntax. It uses two F sites in a row with N (North) orientation.

MACRO myTest
CLASS CORE ;
SIZE 8.0 BY 7.0 ; #Width = 2 * Fsite width, height = Fsite height
SITE Fsite 0 0 N DO 2 BY 1 STEP 4.0 0 ; #Xstep = 4.0 = Fsite width
...
END myTest

This definition produces a cell with the sites shown in Figure 1-28.

Figure 1-29

SIZE width BY height

Specifies a placement bounding rectangle, in microns, for the macro. The bounding rectangle always stretches from (0, 0) to the point defined by SIZE. For example, given SIZE 10 BY 40, the bounding rectangle reaches from (0, 0) after adjustment due to the ORIGIN statement, to (100, 400).

Placers assume the placement bounding rectangle cannot overlap placement bounding rectangles of other macros, unless OBS OVERLAP shapes are used to create a non-rectangular area.

After placement, a DEF COMPONENTS placement pt indicates where the lower-left corner of the placement bounding rectangle is placed after any possible rotations or flips. The bounding rectangle width and height should be a multiple of the placement grid to allow for abutting cells.

For blocks, the placement bounding rectangle typically contains all pin and blockage geometries, but this is not required. For example, typical standard cells have pins that lie outside the bounding rectangle, such as power pins that are shared with cells in the next row above them.

SYMMETRY {X | Y | R90}

Specifies which macro orientations should be attempted by the placer before matching to the site of the underlying rows. In general, most standard cell macros should have symmetry X Y. N (North) is always a legal candidate. For each type of symmetry defined, additional orientations become legal candidates. For more information on defining symmetry, see “Defining Symmetry”.

Possible orientations include:

X

N and FS orientations should be tried.

Y

N and FN orientations should be tried.

X Y

N, FN, FS, and S orientations should all be tried.

R90

Specify this value only for non-standard cells.

If you do not specify a SYMMETRY statement, only N orientation is tried.
If you do not specify a SYMMETRY statement, only N orientation is tried.

For corner I/O pads, if the library includes BOTTOMLEFT, BOTTOMRIGHT, TOPLEFT, and TOPRIGHT I/O corner cells, then they are placed in North orientation (no flipping). However, if the library includes only one type of corner I/O, then SYMMETRY in x and y are required to create the rows for all four of them.

Defining Macro Properties to Create 32/28 nm and Smaller Nodes Rules

You can include macro layer properties in your LEF file to create 32/28 nm and smaller nodes rules that currently are not supported by existing LEF syntax. The properties are specified inside the Macro statements where they can be seen with other rules.

Before you can reference them, properties must be defined at the beginning of the LEF file in the PROPERTYDEFINITIONS statement, immediately before the first Macro statement.

All properties use the following syntax within the LEF PROPERTYDEFINITIONS statement:

PROPERTYDEFINITIONS
MACRO propName STRING ["stringValue"] ;
PIN propName STRING ["stringValue"] ;
END PROPERTYDEFINITIONS

The property definitions for the macro properties are as follows:

PROPERTYDEFINITIONS
     MACRO LEF58_ACCESSAREA STRING ;
     MACRO LEF58_ALIGNPGVIATOTRACK STRING ;
     MACRO LEF58_ALLPINSCONNECTED STRING ;
     MACRO LEF58_CLASS STRING ;
     MACRO LEF58_CONSTRAINTAREATYPE STRING ;
     MACRO LEF58_EDGETYPE STRING ;
     MACRO LEF58_EEQ STRING ;
     MACRO LEF58_FOREIGN STRING ;
     MACRO LEF58_LAYERMASKSHIFT STRING ;
     MACRO LEF58_OBSPARTIAL STRING ;
     MACRO LEF58_OBSSPACING STRING ;
END PROPERTYDEFINITIONS

Access Area Rule

The access area rule can be used on the macro to specify a via access area on the specified layer.

You can specify the access area rule by using the following property definition:
PROPERTY LEF58_ACCESSAREA
   "ACCESSAREA {LAYER layerName RECT pt pt [CUTCLASS className]
   [EXCEPTEXTRACUT]}...
   ; " ;

Where:

ACCESSAREA {LAYER layerName RECT pt pt }...

Specifies a via access area on layerName, which must be a cut layer. All the cuts of a via connected to any pin shape on the bottom metal layer that overlaps the given area in RECT must be inside the given area. If there are multiple via access areas overlapping a pin shape, the entire size of the cuts of a via connected to the pin need to be inside one of the areas. Different via access areas should not overlap or be abutted. For a MUSTJOINALLPORTS pin, the given area must overlap with all of the pin shapes on the bottom metal layer. Then, the cuts on each of the individual pin shapes must be inside the given area and must be connected by a same-metal wire on the above metal layer as well. This construct can only be defined on standard cells with MACRO CLASS of CORE.

Type: Float, specified in microns

CUTCLASS className

Specifies the via access area for the given className, which is connected to the pin shapes. Without CUTCLASS, the via access area would be applied to vias of any cut class. Multiple via access areas could be defined for different cut classes. If a cut class does not have a corresponding via access area defined, the vias of that cut class could be connected to the pins without any restriction.

Type: String

EXCEPTEXTRACUT

Specifies that the via access area is not applied to vias with multiple cuts connected to a single pin shape. If a via pillar with multiple wires on the above metal layer of the pin shape layer is used, this via access area does not need to be honored. For example, if a via pillar with 2x2 cuts is connected to a MUSTJOINALLPORTS with two pin shapes, this via access area could be ignored.

Area Access Rule Examples

Align PG Via to Track Rule

The align PG via to track attribute can be used on the macro to align the power or ground cell vias to the given tracks defined in the PG via track rule in PGTRACKVIA.

You can specify the align PG via to track attribute by using the following property definition:

PROPERTY LEF58_ALIGNPGVIATOTRACK 
"ALIGNPGVIATOTRACK
   ;..." ;

Where:

ALIGNPGVIATOTRACK

Specifies that all the power or ground cell vias of this macro should be aligned to the tracks defined in PGVIATRACK in the library property in a tech LEF file.

All Pins Connected Rule

The all pins connected rule can be used to specify that all of the pins in the macro are strongly connected internally.

You can specify the all pins connected rule by using the following property definition:

PROPERTY LEF58_ALLPINSCONNECTED
   "ALLPINSCONNECTED
   ; " ;

Where:

ALLPINSCONNECTED

Specifies that all of the pins in this macro are strongly connected internally. All of the pins should only have one port. This construct could be defined only in a MACRO with CLASS COVER.

Class Rule

You can use the class rule to define a macro as a special cover macro for metal filling purpose.

You can create class rule by using the following property definition:

PROPERTY LEF58_CLASS 
"CLASS 
     {COVER [BUMP | FILL]
     | RING
     | BLOCK [BLACKBOX | SOFT]
     | PAD [INPUT | OUTPUT | INOUT | POWER | SPACER | AREAIO]
     | CORE [FEEDTHRU | TIEHIGH | TIELOW | SPACER | ANTENNACELL
         | WELLTAP [TAPWALL] [TAPTYPE typeName]]
     | ENDCAP {PRE | POST | TOPLEFT | TOPRIGHT | BOTTOMLEFT
         | BOTTOMRIGHT
         | TOPEDGE | BOTTOMEDGE | LEFTEDGE | RIGHTEDGE 
         | LEFTEVENSITEEDGE | LEFTODDSITEEDGE
         | RIGHTEVENSITEEDGE | RIGHTODDSITEEDGE
         | LEFTTOPEDGE | RIGHTTOPEDGE 
         | LEFTBOTTOMEDGE | RIGHTBOTTOMEDGE
         | LEFTTOPEVENSITEEDGE | LEFTTOPODDSITEEDGE
         | RIGHTTOPEVENSITEEDGE | RIGHTTOPODDSITEEDGE
         | LEFTBOTTOMEVENSITEEDGE | LEFTBOTTOMODDSITEEDGE
         | RIGHTBOTTOMEVENSITEEDGE | RIGHTBOTTOMODDSITEEDGE
         | LEFTTOPCORNER | RIGHTTOPCORNER 
         | LEFTBOTTOMCORNER | RIGHTBOTTOMCORNER
         | LEFTTOPEVENSITECORNER | LEFTTOPODDSITECORNER
         | RIGHTTOPEVENSITECORNER | RIGHTTOPODDSITECORNER
         | LEFTBOTTOMEVENSITECORNER
         | LEFTBOTTOMODDSITECORNER
         | RIGHTBOTTOMEVENSITECORNER 
         | RIGHTBOTTOMODDSITECORNER
         | LEFTEDGETOPBORDER
         | LEFTEDGEBOTTOMBORDER
         | RIGHTEDGETOPBORDER
         | RIGHTEDGEBOTTOMBORDER
         | LEFTTOPEDGENEIGHBOR
         | RIGHTTOPEDGENEIGHBOR
         | LEFTBOTTOMEDGENEIGHBOR
         | RIGHTBOTTOMEDGENEIGHBOR}
         | LEFTTOPCORNERNEIGHBOR 
         | RIGHTTOPCORNERNEIGHBOR 
         | LEFTBOTTOMCORNERNEIGHBOR 
         | RIGHTBOTTOMCORNERNEIGHBOR 
         | LEFTCORNERTOPBORDER
         | RIGHTCORNERTOPBORDER
         | LEFTCORNERBOTTOMBORDER
         | RIGHTCORNERBOTTOMBORDER
         | TOPCORNEREDGENEIGHBOR
         | BOTTOMCORNEREDGENEIGHBOR
         | TSVTOPEDGE | TSVBOTTOMEDGE
         | TSVLEFTEDGE | TSVRIGHTEDGE
         | TSVLEFTTOPCORNER | TSVLEFTBOTTOMCORNER
         | TSVRIGHTTOPCORNER | TSVRIGHTBOTTOMCORNER
         | TSVLEFTTOPEDGE | TSVLEFTBOTTOMEDGE
         | TSVRIGHTTOPEDGE | TSVRIGHTBOTTOMEDGE
         | TSVLEFTTOPEDGENEIGHBOR
         | TSVRIGHTTOPEDGENEIGHBOR
         | TSVLEFTBOTTOMEDGENEIGHBOR
         | TSVRIGHTBOTTOMEDGENEIGHBOR
         | TSVLEFTTOPCORNERNEIGHBOR
         | TSVRIGHTTOPCORNERNEIGHBOR
         | TSVLEFTBOTTOMCORNERNEIGHBOR
         | TSVRIGHTBOTTOMCORNERNEIGHBOR}
         [TAPWALL] [TAPTYPE typeName]
     }
  ; " ;

Where:

All other keywords are same as the existing macro CLASS syntax.

FILL

Specifies that the macro is a special cover macro for metal filling purpose.

LEFTCORNERTOPBORDER | RIGHTCORNERTOPBORDER
| LEFTCORNERBOTTOMBORDER | RIGHTCORNERBOTTOMBORDER

Specifies a left or right edge endcap cell, which is on top or bottom a corner cell. For example, LEFTCORNERTOPBORDER would be placed on the left edge and on top of a corner cell.

LEFTEDGETOPBORDER | LEFTEDGEBOTTOMBORDER | RIGHTEDGETOPBORDER | RIGHTEDGEBOTTOMBORDER

Specifies a left or right edge endcap cell, which is right next to the LEFTTOPEDGE/LEFTBOTTOMEDGE or RIGHTTOPEDGE/RIGHTBOTTOMEDGE cell.

LEFTEVENSITEEDGE | LEFTODDSITEEDGE
| RIGHTEVENSITEEDGE | RIGHTODDSITEEDGE
| LEFTTOPEVENSITEEDGE | LEFTTOPODDSITEEDGE
| RIGHTTOPEVENSITEEDGE | RIGHTTOPODDSITEEDGE
| LEFTBOTTOMEVENSITEEDGE | LEFTBOTTOMODDSITEEDGE
| RIGHTBOTTOMEVENSITEEDGE | RIGHTBOTTOMODDSITEEDGE
| LEFTTOPEVENSITECORNER | LEFTTOPODDSITECORNER
| RIGHTTOPEVENSITECORNER | RIGHTTOPODDSITECORNER
| LEFTBOTTOMEVENSITECORNER
| LEFTBOTTOMODDSITECORNER
| RIGHTBOTTOMEVENSITECORNER
| RIGHTBOTTOMODDSITECORNER

Specifies that the macro with *EVENSITE* or *ODDSITE* endcap type has even or odd site. These are used to always form even number of sites horizontally, including the endcap cells.

LEFTTOPCORNERNEIGHBOR | RIGHTTOPCORNERNEIGHBOR
| LEFTBOTTOMCORNERNEIGHBOR | RIGHTBOTTOMCORNERNEIGHBOR

Specifies a top or bottom edge endcap cell, which is right next to the LEFTTOPCORNER/RIGHTTOPCORNER or LEFTBOTTOMCORNER/RIGHTBOTTOMCORNER cell. When all four cells are specified, they are placed in R0 (or MX) orient, abutting the CORNER cells on the same row. If only one of the four cells, for example RIGHTTOPCORNERNEIGHBOR, is specified, it will be flipped and rotated to be used in all four locations, provided the row of the location needing the bottom edge is flipped (MX). If both top and bottom rows are in R0 orient, the same cell cannot be used in place of LEFT/RIGHTBOTTOMCORNERNEIGHBOR, as that would result in shorting power to ground. If two cells, TOP and BOTTOM, are provided, they can be flipped around the Y axis to be used in both the LEFT and RIGHT locations.

LEFTTOPEDGENEIGHBOR | RIGHTTOPEDGENEIGHBOR | LEFTBOTTOMEDGENEIGHBOR | LEFTBOTTOMEDGENEIGHBOR

Specifies a top or bottom edge endcap cell, which is right next to the LEFTTOPEDGE/LEFTBOTTOMEDGE or RIGHTTOPEDGE/RIGHTBOTTOMEDGE cell. When all four types of *NEIGHBOR are defined, they are placed in the R0 or MX orientation. If only LEFTTOPEDGENEIGHBOR and LEFTBOTTOMEDGENEIGHBOR are defined, they can be used by y-flipping for RIGHTTOPEDGENEIGHBOR and RIGHTBOTTOMEDGENEIGHBOR. However, LEFTTOPEDGENEIGHBOR and RIGHTTOPEDGENEIGHBOR cannot be x-flipped to replace LEFTBOTTOMEDGENEIGHBOR and LEFTBOTTOMEDGENEIGHBOR because the power/ground pins cannot be matched.

TAPTYPE typeName

Identifies different well tap cells with CLASS WELLTAP or end cap cells with CLASS ENDCAP, which would also serve tap cell purpose, by tagging them with the name, typeName. Other LEF constructs or properties can refer to certain well tap cells by typeName, and define well tap specific information on them.
Type: String

TAPWALL

Specifies a special well tap cell or a special ENDCAP cell that is also serving tap wall purpose, which could be used to break OD diffusion and aligned vertically to form a tap wall.

TOPCORNEREDGENEIGHBOR | BOTTOMCORNEREDGENEIGHBOR

Specifies a top or bottom edge endcap cell as TOPCORNEREDGENEIGHBOR or BOTTOMCORNEREDGENEIGHBOR, which is between a corner cell and an edge cell.

TOPEDGE | BOTTOMEDGE | LEFTEDGE | RIGHTEDGE
| LEFTTOPEDGE | RIGHTTOPEDGE
| LEFTBOTTOMEDGE | RIGHTBOTTOMEDGE
| LEFTTOPCORNER | RIGHTTOPCORNER
| LEFTBOTTOMCORNER | RIGHTBOTTOMCORNER

Specifies that the macro has nwell resided on certain edge or corner of the endcap cells. For example, the TOPEDGE keyword indicates that the endcap cell has n-well on the top edge, while LEFTTOPEDGE indicates that nwell exists on both top and left edges. The LEFTTOPCORNER keyword indicates that nwell only exists on the top left corner.

TSVTOPEDGE | TSVBOTTOMEDGE | TSVLEFTEDGE | TSVRIGHTEDGE
| TSVLEFTTOPCORNER | TSVLEFTBOTTOMCORNER
| TSVRIGHTTOPCORNER | TSVRIGHTBOTTOMCORNER
| TSVLEFTTOPEDGE | TSVLEFTBOTTOMEDGE
| TSVRIGHTTOPEDGE | TSVRIGHTBOTTOMEDGE

Specifies special endcap cells around TSV with a keepout zone. TSVTOPEDGE, TSVBOTTOMEDGE, TSVLEFTEDGE and TSVRIGHTEDGE are added on the corresponding edges around TSV. The rest of TSV*EDGE are added on the corners. TSV*CORNER are special end-corner cells when they are next to a regular blockage or block.

TSVLEFTTOPEDGENEIGHBOR | TSVRIGHTTOPEDGENEIGHBOR
| TSVLEFTBOTTOMEDGENEIGHBOR | TSVRIGHTBOTTOMEDGENEIGHBOR

Specifies a top- or bottom-edge endcap cell, which is right next to the TSVLEFTTOPEDGE/TSVLEFTBOTTOMEDGE or TSVRIGHTTOPEDGE/TSVRIGHTBOTTOMEDGE cell. When all four types of TSV*EDGENEIGHBOR cells are defined, they are placed in the R0 or MX orientation. If only TSVLEFTTOPEDGENEIGHBOR and TSVLEFTBOTTOMEDGENEIGHBOR are defined, they can be y-flipped for TSVRIGHTTOPEDGENEIGHBOR and TSVRIGHTBOTTOMEDGENEIGHBOR. However, TSVLEFTTOPEDGENEIGHBOR and TSVRIGHTTOPEDGENEIGHBOR cannot be x-flipped to replace TSVLEFTBOTTOMEDGENEIGHBOR and TSVRIGHTBOTTOMEDGENEIGHBOR because the power/ground pins cannot be matched.

TSVLEFTTOPCORNERNEIGHBOR | TSVRIGHTTOPCORNERNEIGHBOR
| TSVLEFTBOTTOMCORNERNEIGHBOR | TSVRIGHTBOTTOMCORNERNEIGHBOR

Specifies a top- or bottom-edge endcap cell, which is right next to the TSVLEFTTOPCORNER/TSVRIGHTTOPCORNER or TSVLEFTBOTTOMCORNER/TSVRIGHTBOTTOMCORNER cell. When all four types of TSV*CORNERNEIGHBOR cells are defined, they are placed in the R0 or MX orientation. If only one of the four cells, such as TSVRIGHTTOPCORNERNEIGHBOR, is specified, it will be flipped and rotated to be used in all four locations, provided the row of the location needing the bottom edge is flipped (MX). If both the top and bottom rows are in R0 orient, the same cell cannot be used in place of TSVLEFTBOTTOMCORNERNEIGHBOR/TSVRIGHTBOTTOMCORNERNEIGHBOR, as that would result in shorting power to ground. If only TSVLEFTTOPCORNERNEIGHBOR and TSVLEFTBOTTOMCORNERNEIGHBOR are provided, they can be y-flipped for TSVRIGHTTOPCORNERNEIGHBOR and TSVRIGHTBOTTOMCORNERNEIGHBOR.

Class Rule Examples

Constraint Area Type Rule

The constraint area type rule can be used to define a list of constraint rectangular areas.

You can create a constraint area type rule by using the following property definition:

PROPERTY LEF58_CONSTRAINTAREATYPE
   "“CONSTRAINTAREATYPE typeName {RECT pt pt}...
    ;...” ;

Where:

CONSTRAINTAREATYPE typeName {RECT pt pt}...

Defines a list of constraint rectangular areas in RECT with respect to the cell origin with type name, typeName. Then, rules such as length limit, could be defined on those areas in separate LEF constructs, such as CONSTRAINTLENGTH.

Type: Float, specified in microns

Edge Type Rule

The edge type rule can be used to define edge types for right and left edges.

You can create an edge type rule by using the following property definition:

PROPERTY LEF58_EDGETYPE 
"EDGETYPE {RIGHT | LEFT | TOP | BOTTOM}
    edgeType | BOTHSOURCE | SOURCEDRAIN | DRAINSOURCE | BOTHDRAIN 
    | BOTHFLOATING 
    [CELLROW cellRow  | HALFROW halfRow | RANGE xLow xHigh]
    ;..." ;

Where:

CELLROW cellRow

Defines which cell row, cellRow, the edgeType is defined on for multiple height cells, which can only be defined on LEFT or RIGHT edges. The legal value of cellRow is from 1 to n, where n is number of cell height of the cell. By default, the edgeType is applied to the entire edge covering all cell rows. For example, 1 will apply edgeType to the bottom most cell row only.

EDGETYPE { RIGHT | LEFT | TOP | BOTTOM } edgeType
|BOTHSOURCE | SOURCEDRAIN | DRAINSOURCE | BOTHDRAIN | BOTHFLOATING

Defines an edge type, edgeType, on the specified edge (RIGHT, LEFT, TOP, or BOTTOM) such that a spacing can be defined in CELLEDGESPACINGTABLE by referring to the types. For a macro, you can specify multiple statements on one edge.

BOTHSOURCE, SOURCEDRAIN, DRAINSOURCE, BOTHDRAIN, and BOTHFLOATING are special keywords that can be defined only on the LEFT or RIGHT edges:

  • BOTHSOURCE indicates that the entire portion of that edge is a source.
  • BOTHDRAIN indicates that the entire portion of that edge is a drain.
  • BOTHFLOATING indicates that the entire portion of that edge is floating.
  • SOURCEDRAIN indicates that the top portion is a source and the bottom portion is a drain.
  • DRAINSOURCE indicates that the top portion is a drain and the bottom portion is a source.

Edges of those special types may or may not have corresponding spacing defined in CELLEDGESPACINGTABLE. They are used for ensuring a common edge type be defined in different cell libraries such that spacing can be defined in some combinations on those edge types in CELLEDGESPACINGTABLE.

See Figure 1-39.

HALFROW halfRow

Defines the edge type per half row, which can be defined only on the LEFT or RIGHT edges. For a single-height cell, the halfRow value of 1 would apply the given edge type on the bottom half of the cell while a value of 2 would apply the given edge type on the top half of the cell.

Multiple height cells would have the same meaning and values of 3 or above would be used to represent the second and higher rows. For example, a double-height cell can have halfRow values from 1 to 4, where the halfRow value of 1 would apply the given edge type on the bottom half of the first row while a value of 4 would apply the given edge type on the top half of the second row. See Figure 1-38.

Type: Integer

RANGE xLow xHigh

Defines a partial range of an edge that the type should be labeled. This can only be defined on TOP or BOTTOM edges.

Type: Float, specified in microns

You can define multiple EDGETYPE statements on an edge, including single height cells, such that different type of constraints can be defined on an edge.

Edge Type Rule Examples

EEQ Rule

You can use the EEQ rule to specify the electrically equivalent (EEQ) variant for macros with class CORE standard cells.

You can create an EEQ rule by using the following property definition:

PROPERTY LEF58_EEQ 
     "EEQ macroName [VARIANT num]
     ;... " ;

Where:

All other keywords are same as the existing macro EEQ syntax.

VARIANT num

Specifies the EEQ variant number as num. This should be defined consistently with CELLVARIANTS, which indicates the usage. This construct should be applied only on MACRO with CLASS CORE standard cells.
Type: Integer

Foreign Rule

You can use the foreign rule to indicate that the foreign structure of the specified foreign orient should be used if a component of the macro matches one of the given component orientations.

You can create foreign rule by using the following property definition:

PROPERTY LEF58_FOREIGN 
     "FOREIGN foreignCellName [pt [orient]] 
          [COMPORIENT foreignOrientName {compOrient}...]...
     ;... " ;

Where:

All other keywords are same as the existing macro FOREIGN syntax.

COMPORIENT foreignOrientName {compOrient}...

Specifies that the foreign structure of foreignOrientName should be used if a component of the macro matches one of the given component orientations specified using compOrient. Otherwise, all the other components will use foreignCellName.
Values: N, S, E, W, FN, FS, FE, or FN

FOREIGN Rule Examples

The following example indicates that the foreign structure of foreign orient EFG should be applied if the instance is placed with orientation of S or FS, and all the other instances use the foreign orient ABC.

PROPERTY LEF58_FOREIGN
     "FOREIGN ABC COMPORIENT EFG S FS ; " ;

Layer Mask Shift Rule

You can create a layer mask shift rule to specify that the mask could be shifted on the given layers.

You can define a layer mask shift rule by using the following property definition:

PROPERTY LEF58_LAYERMASKSHIFT
"LAYERMASKSHIFT layer1 [layer2 ...]
     ;" ;

Where:

LAYERMASKSHIFT layer1 [layer2 ...]

Specifies that mask could be shifted on the given layers only on the given MACRO. LAYERMASKSHIFT should not be specified as a library property if any macro has this LAYERMASKSHIFT construct. In addition, if FIXEDMASK is defined as a library property, this LAYERMASKSHIFT construct would override it and allow mask shifting on the given layers on this macro.

Type: String

OBS Partial Rule

You can use the OBS partial rule to indicate a partially routing blockage.

You can create a OBS partial rule by using the following property definition:

PROPERTY LEF58_OBSPARTIAL
"OBSPARTIAL {LAYER layerName 
WIDTH width SPACING spacing RECT pt pt}...
; " ;

Where:

OBSPARTIAL {LAYER layerName
WIDTH
width SPACING spacing RECT pt pt }...

Specifies a partially routing blockage. Any wires in the given RECT area on layerName must have minimum width of width and spacing of spacing. In addition, wires cannot change layer within that area.
Type:  Float, specified in microns

OBS Partial Rule Example

MACRO A
...
PROPERTY LEF58_OBSPARTIAL  
   "OBSPARTIAL LAYER M2 WIDTH 0.2 SPACING 0.2
       RECT -1.0 -1.0 10.0 8.0 ; " ;

Figure 1-42 Illustration of OBS Partial Rule

OBS Spacing Rule

You can use the OBS spacing rule to specify spacing for the OBS of the macro.

You can create a OBS spacing rule by using the following property definition:

PROPERTY LEF58_OBSSPACING
  "OBSSPACING {FULLDRC | MIN | spacing} [LAYER layer]...
  ; " ;

Where:

FULLDRC

Specifies that any OBS shapes without SPACING or DESIGNRULEWIDTH should be treated as a real geometry so all design rule check (DRC) rules will be checked for these shapes. By default, blocks and pad cells (MACROs with a CLASS of BLOCK, RING or PAD) treat OBS shapes as “abstract” blockages to prevent routing over the block, and only simple DRC spacing checks are done to the OBS shapes. Note that standard cells (CLASS CORE or ENDCAP) always treat OBS shapes as real geometry with full DRC checks. Therefore, FULLDRC should normally only be used on one or two top routing layers of a block that has very sparse routing to make room for the top-level to route across the block. Note that this may cause extra cross-coupling between the block and top-level routing, so FULLDRC should be used carefully.

LAYER layer

Specifies that the given spacing would be applied on OBS of this macro only on the given layer.

OBSSPACING {MIN | spacing}

Specifies that OBS of this macro would either use min spacing if MIN is given or the given spacing value. This is equivalent to using OBS SPACING value for all the OBS shapes in this LEF MACRO. If LAYER is specified, the given spacing is applied on OBS of this macro only on the given layer. If LAYER is not specified, the spacing value applies to all the OBS shapes. Note that this construct must be used with caution because the defined spacing would always be used even on a neighbor wide wire, which may require a larger spacing.
Type:  Float, specified in microns

OBS Spacing Rule Examples

Place Within Rule

You can use the OBS spacing rule to specify place within conditions for a filler cell.

You can create a place within rule by using the following property definition:

PROPERTY LEF58_PLACEWITHIN
  "PLACEWITHIN within PRL prl {WITH|WITHOUT} LAYER {layerName}...
  ; " ;

Where:

PLACEWITHIN within PRL prl {WITH|WITHOUT} LAYER {layerName}...

Specifies that this filler cell must be placed under certain within conditions, and these conditions should be fulfilled horizontally on the same row.

WITH means that this cell must be placed horizontally within within on both sides of another cell with shapes on any given layer in layerName and should have a PRL with that cell greater than or equal to prl. Abutment with such a neighboring cell would fulfill the condition on that side.

WITHOUT means that this cell must be placed horizontally in a location without a neighboring cell with shapes on any given layer in layerName within within and having a PRL with that cell greater than or equal to prl. This means that either the spacing to such a neighboring cell should be greater than or equal to within or the PRL to that cell should be less than prl. Abutment with such a neighboring cell is allowed on only one side, and the other side needs to fulfill the within and PRL conditions. In other words, abutment on both sides would be a violation.

This cell should contain shapes on a layer with type ABUTFILLER. layerName should be a layer with type ABUTLOGIC.

Type: Float, specified in microns

Figure 1-43 Illustration of the Place Within Rule Using WITH

Figure 1-44 Illustration of the Place Within Rule Using WITHOUT

REQ Rule

You can define a REQ rule by using the following property definition:

PROPERTY LEF58_REQ
   "REQ macroName 
    ; " ;

Where:

REQ macroName

Specifies that the macro being defined should be a router-preferred equivalent (REQ) to the previously defined macroName. REQ cells can be placed at the same site to achieve a different routing pattern depending on the design context. This is different from EEQ cells, which provide cell placement flexibility at different sites. In addition, timing variation of REQ cells can be different from EEQ cells. This construct can only be defined on macros with the class CORE standard cells and should be mutually exclusive with EEQ.

Type: String

Tap Center Offset Rule

You can use the tap center offset rule to specify an offset value from the cell center from which the tap distance should be measured.

You can create a tap center offset rule by using the following property definition:

PROPERTY LEF58_TAPCENTEROFFSET
  "TAPCENTEROFFSET
    {offset | {HALFROW rowNum [LEFT|RIGHT] offset}...}
  ; " ;

Where:

TAPCENTEROFFSET
{offset | {HALFROW
rowNum [LEFT|RIGHT] offset}...}

Specifies an offset value from the cell center from which the tap distance should be measured. A positive value moves the starting point away from the center by the given amount. A negative value moves the starting point behind the center or away from the center in the other direction.
Type: Float, specified in microns

HALFROW specifies that the offset could be defined on a half row basis. rowNum specifies the half row, with respect to the cell origin, on which the offset is defined.

LEFT|RIGHT specifies that the offset could be defined on the left or right sides on a half cell row basis. Left and right is referred with respect to the cell origin.

Tap Center Offset Rule Example

MACRO A
PROPERTY LEF58_TAPCENTEROFFSET “
     TAPCENTEROFFSET HALFROW 1 2.4 
          HALFROW 2 LEFT -1.2 HALFROW 2 RIGHT 3.6 ; “ ;
...
END A

Figure 1-45 Illustration of Tap Center Offset Rule

Defining Cover Macros

If you define a cover macro with its actual size, some place-and-route tools cannot place the rest of the cells in your design because it uses the cell boundary to check for overlaps. You can resolve this in two ways:

Defining Symmetry

Symmetry statements specify legal orientations for sites and macros. Figure 1-45 illustrates the normal orientations for single-height, flipped and abutted rows with standard cells and sites.

Figure 1-46 Normal Orientations for Single-Height Rows

The following examples describe typical combinations of orientations for standard cells. Applications typically create only N (or FS for flipped) row orientations for horizontal standard cell rows; therefore, the examples describe these two rows.

Example 1-6 Single-Height Cells

Single-height cells for flipped and abutted rows should have SITE symmetry Y and MACRO symmetry X Y. These specifications allow N and FN macros in N rows, and FS and S macros in FS rows, see Figure 1-46. These symmetries work with flipped and abutted rows, as well as rows that are not flipped and abutted, so if the rows are all N orientation, the cells all have N or FN orientation. The extra MACRO symmetry of X is not required in this case, but causes no problems.

Figure 1-47 Legal Placements for Row Sites with Symmetry Y

Example 1-7 Double-Height Cells

Double-height cells that are intended to align with flipped and abutted single-height rows should have SITE symmetry X Y and MACRO symmetry X Y. These symmetries allow all four cell orientations (N, FN, FS, and S) to fit inside the double-height row (see Figure 1-47). Usually, double-height rows are just N orientation rows that are abutted and aligned with a pair of single-height flipped and abutted rows.

Figure 1-48 Legal Placements for Single-Height Row Sites with Symmetry Y and Double-Height Row Sites with Symmetry X Y

Example 1-8 Special Orientations

Some single-height cells have special orientation needs. For example, the design requires flipped and abutted rows, but only N and FS orientations are allowed because of the special layout of well taps on the right side of a group of cells that borrow from the left side of the next cell. That is, you cannot place an N and FN cell against each other in one row because only N cells are allowed in an N row. In this case, the SITE symmetry should not be defined, and the MACRO symmetry should be X. A MACRO symmetry of X Y can also be defined because the Y-flipped macros (FN and S orientations) do not match the N or FS rows. See Figure 1-48 for the different combinations when the SITE has no symmetry.

Figure 1-49 Legal Placements for Row Sites with No Symmetry

Example 1-9 Vertical Rows

Vertical rows use N or FN row and site orientations. The flipped, abutted vertical row orientation is N and FN, rather than the horizontal row orientation of N and FS. Otherwise, the meaning of the site symmetries and macro symmetries is the same as those for horizontal rows.

Single-height sites are normally given symmetry X, and single-height cells are normally given symmetry X Y. Example d in Figure 1-49 shows the legal placement for a site with symmetry X, and the typical standard cell MACRO symmetry X Y.

Figure 1-50 Legal Placements for Vertical Row Sites With Symmetry X

Layer Geometries

     { LAYER layerName 
    [EXCEPTPGNET]
    [SPACING minSpacing | DESIGNRULEWIDTH value] ;
  [WIDTH width ;]
  { PATH [MASK maskNum] pt ... ; 
  | PATH [MASK maskNum] ITERATE pt ... stepPattern ;
  | RECT [MASK maskNum] pt pt ; 
  | RECT [MASK maskNum] ITERATE pt pt stepPattern ;
  | POLYGON [MASK maskNum] pt pt pt pt ... ; 
  | POLYGON [MASK maskNum] ITERATE pt pt pt pt ... stepPattern ;
  } ...
| VIA [MASK viaMaskNum] pt viaName ; 
| VIA ITERATE [MASK viaMaskNum] pt viaName stepPattern ;
} ...

Used in the macro obstruction (OBS) and pin port (PIN) statements to define layer geometries in the design.

DESIGNRULEWIDTH value

Specifies the effective design rule width. If specified, the obstruction or pin is treated as a shape of this width for all spacing checks. If you specify DESIGNRULEWIDTH, you cannot specify the SPACING argument. As a lot of spacing rules in advanced nodes no longer just rely on wire width, DESIGNRULEWIDTH is not allowed for 20nm and below nodes.
Type: Float, specified in microns

EXCEPTPGNET

Indicates that the obstruction shapes block signal routing, but do not block power or ground routing. This can be used to block signal routes that might cause noise, but allow connections to power and ground pins.

ITERATE

Creates an array of the PATH, RECT, POLYGON, or VIA geometry, as specified by the given step pattern. ITERATE specifications simplify the definitions of cover macros. The syntax for stepPattern is defined as follows:

DO numX BY numY STEP spaceX spaceY

numX

Specifies the number of columns of points.

numY

Specifies the number of rows of points.

spaceX spaceY

Specifies the spacing, in distance units, between the columns and rows of points.

LAYER layerName

Specifies the layer on which to place the geometry.

Note: For macro obstructions, you can specify cut, implant, or overlap layers.

MASK maskNum

Specifies which mask from double- or triple-patterning to use for this shape. The maskNum variable must be a positive integer. Most applications only support values of 1, 2, or 3.

Shapes without any defined mask have no mask set (they are considered uncolored). The uncolored PIN shapes can be assigned to an arbitrary mask as long as they do not have a spacing conflict with neighbor objects. The meaning of uncolored OBS shapes depends on the cell. For standard cell MACROs (with a SITE that is CLASS CORE), the uncolored OBS shapes are considered to be real metal shapes that can be assigned to any mask as long as no mask spacing conflicts occur. For other MACRO types, uncolored OBS shapes are assumed to be abstractions that may be any mask, so other shapes must be spaced far enough away to avoid a violation to any mask shape at that location.

MASK viaMaskNum

Specifies which mask for double- or triple-patterning lithography to be applied to via shapes on each layer.

The viaMaskNum is a hex-encoded 3 digit value of the form:     

<topMaskNum><cutMaskNum><bottomMaskNum>

For example, MASK 113 means the top metal and cut layer maskNum is 1, and the bottom metal layer maskNum is 3. A value of 0 means the shape on that layer has no mask assignment (is uncolored), so 013 means the top layer is uncolored. If either the first or second digit is missing, they are assumed to be 0, so 013 and 13 means the same thing. Most applications only support maskNum values of 0, 1, 2, or 3 for double or triple patterning.

The topMaskNum and bottomMaskNum variables specify which mask the corresponding metal shape belongs to. The via-master metal mask values have no effect. For the cut-layer, the cutMaskNum defines the mask for the bottommost, and then the leftmost cut. For multi-cut vias, the via-instance cut masks are derived from the via-master cut mask values. The via-master must have a mask defined for all of the cut shapes and every via-master cut mask is "shifted" (1 to 2, 2 to 1 for two mask layers, and 1 to 2, 2 to 3, 3 to 1 for three mask layers) so the lower-left cut matches the cutMaskNum value. See Example 1-11 .

Similarly, for the metal layer, the topMaskNum/bottomMaskNum would define the mask for the bottom-most, then leftmost metal shape. For multiple disjoint metal shapes, the via-instance metal masks are derived from the via-master metal mask values. The via-master must have a mask defined for all of the metal shapes, and every via-master metal mask is “shifted” (1->2, 2->1 for two mask layers, 1->2, 2->3, 3->1 for three mask layers) so the lower-left cut matches the topMaskNum/bottomMaskNum value.

Shapes without any defined mask that need to be assigned, can be assigned to an arbitrary choice of mask by applications.

PATH pt

Creates a path between the specified points, such as pt1 pt2 pt3. The path automatically extends the length by half of the current width on both endpoints to form a rectangle. (A previous WIDTH statement is required.) The line between each pair of points must be parallel to the x or y axis (45-degree angles are not allowed).

You can also specify a path with a single coordinate, in which case a square whose side is equal to the current width is placed with its center at pt.

POLYGON pt pt pt pt

Specifies a sequence of at least three points to generate a polygon geometry. Most fab DRC rules require each polygon edge to be parallel to the x or y axis, or at a 45-degree angle. However, odd-angles are allowed sometimes on a few layers, such as bump layers. Each POLYGON statement defines a polygon generated by connecting each successive point, and then by connecting the first and last points.

RECT pt pt

Specifies a rectangle, where the two points specified are opposite corners of the rectangle. There is no functional difference between a geometry specified using PATH and a geometry specified using RECT.

SPACING minSpacing

Specifies the minimum spacing allowed between this particular OBS and any other shape. While the syntax is shared for both OBS and PIN, it is only intended to be used with OBS shapes. The minSpacing value overrides all other normal LAYER-based spacing rules, including wide-wire spacing rules, end-of-line rules, parallel run-length rules, etc. An OBS with SPACING is not “seen” by any other DRC check, except the simple check for minSpacing to any other routing shape on the same layer.  

One common application is to put an OBS SPACING 0 shape on top of some PIN shapes to restrict the access of a router to other parts of the PIN without the OBS shape. This is sometimes needed for cells with large drive strengths to avoid electromigration problems by restricting the router to connect only to the middle of the output pin.

The minSpacing value cannot be larger than the maximum spacing defined in the SPACING or SPACINGTABLE for that layer. Tools may change larger values to the maximum spacing value with a warning.

VIA pt viaName

Specifies the via to place, and the placement location.

WIDTH width

Specifies the width that the PATH statements use. If you do not specify width, the default width for that layer is used. When you specify a width, that width remains in effect until the next WIDTH or LAYER statement. When another LAYER statement is given, the WIDTH is automatically reset to the default width for that layer.

Example 1-10 Layer Geometries

The following example shows how to define a set of geometries, first by using ITERATE statements, then by using individual PATH, VIA and RECT statements.

The following two sets of statements are equivalent:

PATH ITERATE 532.0 534 1999.2 534 
DO 1 BY 2 STEP 0 1446 ;
VIA ITERATE 470.4 475 VIABIGPOWER12
DO 2 BY 2 STEP 1590.4 1565 ;
RECT ITERATE 24.1 1.5 43.5 16.5 
DO 2 BY 1 STEP 20.0 0 ; 
PATH 532.0 534 1999.2 534 ; 
PATH 532.0 1980 1999.2 1980 ;
VIA 470.4 475 VIABIGPOWER12 ;
VIA 2060.8 475 VIABIGPOWER12; 
VIA 470.4 2040 VIABIGPOWER12;
VIA 2060.8 2040 VIABIGPOWER12;
RECT 24.1 1.5 43.5 16.5 ; 
RECT 44.1 1.5 63.5 16.5 ; 

Example 1-11 Layer Geometries - multi-mask patterns

The following example shows how to use multi-mask patterns:

LAYER M1 ;
RECT MASK  2 10 10 11 11 ; 
LAYER M2 ;    
RECT 10 10 11 11 ; 
VIA 5 5 VIA1_1 ; 
VIA MASK 031 15 15 VIA1_2 ; 

This indicates that the:

LAYER M1 ;
RECT MASK  2 10 10 11 11 ; 
LAYER M2 ;    
RECT 10 10 11 11 ; 
VIA 5 5 VIA1_1 ; 
VIA MASK 031 15 15 VIA1_2 ; 

Figure 1-51 Via-master multi-mask patterns

Macro Obstruction Statement

[OBS
{layerGeometries}...
END]

Defines a set of obstructions (also called blockages) on the macro. You specify obstruction geometries using the layer geometry syntax. See “Layer Geometries” for syntax information.

Normally, obstructions block routing, except for when a pin port overlaps an obstruction (a port geometry overrules an obstruction). For example, you can define a large rectangle for a metal1 obstruction and have metal1 port in the middle of the obstruction. The port can still be accessed by a via, if the via is entirely inside the port.

In Figure 1-51, the router can only access the metal1 port from the right. If the metal2 obstruction did not exist, the router could connect to the port with a metal12 via, as long as the metal1 part of the via fit entirely inside the metal1 port.

Figure 1-52

Routing can also connect to such a port on the same layer if the routing does not cross any obstruction by more than a distance of the total of minimum width plus minimum spacing before reaching the pin. This is because the port geometry is known to be “real,” and any obstruction less than a distance of minimum width plus minimum spacing away from the port is not a real obstruction. If the pin is more than minimum width plus minimum spacing away from the obstruction edge, the router can only route to the pin from the layer above or below using a via (see Figure 1-52).

Figure 1-53

If a port is on the edge of the obstruction, a wire can be routed to the port without violations. Pins that are partially covered with obstructions or in apparent violation with nearby obstructions can limit routing options. Even though the violations are not real, the router assumes they are. In these cases, extend each obstruction to cover the pin. The router then accesses the pin as described above.

Benefits of Combining Obstructions

Significant routing time can be saved if obstructions are simplified. Especially in metal1, construct obstructions so that free tracks on the layer are accessible to the router. If most of the routing resource is obstructed, simplify the obstruction modeling by combining small obstructions into a single large obstruction. For example, use the bounding box of all metal1 objects in the cell, rather than many small obstructions, as the bounding box of the obstruction.

You must be sure to model via obstructions over the rest of the cell properly. A single, large cut12 obstruction over the rest of the cell can do this in some cases, as when metal1 resource exists within the cell outside the power buses.

Rectilinear Blocks

Normally, footprint descriptions in LEF are rectangular. However, it is possible to describe rectilinear footprints using an overlap layer. The overlap layer is defined specifically for this purpose and does not contain any routing.

Describe a rectilinear footprint by setting the SIZE of the macro as a whole to a rectangular bounding box, then defining obstructions within the bounding box on the overlap layer. The obstructions on the overlap layer indicate areas within the bounding box which no other macro should overlap. The obstructions should completely cover the rectilinear shape of the macro, but not the portion of the bounding box that might overlap with other macros during placement.

Specify the overlaps for the macro using the OBS statement. To do this, specify a layer of type OVERLAP and then give the overlap geometries, as shown in Figure 1-53.

Figure 1-54

Macro Pin Statement

[PIN pinName
[TAPERRULE ruleName ;]
[DIRECTION {INPUT | OUTPUT [TRISTATE] | INOUT | FEEDTHRU} ;]
[USE { SIGNAL | ANALOG | POWER | GROUND | CLOCK } ;] 
[NETEXPR "netExprPropName defaultNetName" ;]
[SUPPLYSENSITIVITY powerPinName ;]
[GROUNDSENSITIVITY groundPinName ;]
[SHAPE {ABUTMENT | RING | FEEDTHRU} ;]
[MUSTJOIN pinName ;]
{PORT  
  [CLASS {NONE | CORE | BUMP} ;] 
  {layerGeometries} ... 
 END} ... 
[PROPERTY propName propVal ;] ...
[PROPERTY LEF58_ACCESSAREA
   "ACCESSAREA {LAYER layerName RECT pt pt [CUTCLASS className]
   [EXCEPTEXTRACUT]}...
   ; " ;]
[PROPERTY LEF58_ANTENNADIFFAREA
   "ANTENNADIFFAREA [BACKSIDE][PROTECTOR] value [LAYER layerName]
   ; ..." ;]
[PROPERTY LEF58_MUSTJOINALLPORTS
   "MUSTJOINALLPORTS
   ; " ;]
[PROPERTY LEF58_VIAINMUSTJOIN
   "VIAINMUSTJOIN
   ; " ;]
[PROPERTY LEF58_VIAINPINONLY
   "VIAINPINONLY
   ; " ;]
[ANTENNAPARTIALMETALAREA value [LAYER layerName] ;] ...
[ANTENNAPARTIALMETALSIDEAREA value [LAYER layerName] ;] ...
[ANTENNAPARTIALCUTAREA value [LAYER layerName] ;] ...
[ANTENNADIFFAREA value [LAYER layerName] ;] ...
[ANTENNAMODEL {OXIDE1 | OXIDE2 | OXIDE3 | OXIDE4} ;] ...
[ANTENNAGATEAREA value [LAYER layerName] ;] ...
[ANTENNAMAXAREACAR value LAYER layerName ;] ...
[ANTENNAMAXSIDEAREACAR value LAYER layerName ;] ...
[ANTENNAMAXCUTCAR value LAYER layerName ;] ...
END pinName] 

Defines pins for the macro. PIN statements must be included in the LEF specification for each macro. All pins, including VDD and VSS, must be specified. The first pin listed becomes the first pin in the database. List the pins in the following order:

ANTENNADIFFAREA value [LAYER layerName]

Specifies the diffusion (diode) area, in micron-squared units, to which the pin is connected on a layer. If you do not specify a layer name, the value applies to all layers. For more information on process antenna calculation, see Appendix C, “Calculating and Fixing Process Antenna Violations.”

ANTENNAGATEAREA value [LAYER layerName]

Specifies the gate area, in micron-squared units, to which the pin is connected on a layer. If you do not specify a layer name, the value applies to all layers. For more information on process antenna calculation, see Appendix C, “Calculating and Fixing Process Antenna Violations.”

ANTENNAMAXAREACAR value LAYER layerName

For hierarchical process antenna effect calculation, specifies the maximum cumulative area ratio value on the specified layerName, using the metal area at or below the current pin layer, excluding the pin area itself. This is used to calculate the actual cumulative antenna ratio on the pin layer, or the layer above it.

For more information on process antenna calculation, see Appendix C, “Calculating and Fixing Process Antenna Violations.”

ANTENNAMAXCUTCAR value LAYER layerName

For hierarchical process antenna effect calculation, specifies the maximum cumulative antenna ratio value on the specified layerName, using the cut area at or below the current pin layer, excluding the pin area itself. This is used to calculate the actual cumulative antenna ratio for the cuts above the pin layer.

For more information on process antenna calculation, see Appendix C, “Calculating and Fixing Process Antenna Violations.”

ANTENNAMAXSIDEAREACAR value LAYER layerName

For hierarchical process antenna effect calculation, specifies the maximum cumulative antenna ratio value on the specified layerName, using the metal side wall area at or below the current pin layer, excluding the pin area itself. This is used to calculate the actual cumulative antenna ratio on the pin layer or the layer above it.

For more information on process antenna calculation, see Appendix C, “Calculating and Fixing Process Antenna Violations.”

ANTENNAMODEL {OXIDE1 | OXIDE2 | OXIDE3 | OXIDE4}

Specifies the oxide model for the pin. If you specify an ANTENNAMODEL statement, the value affects all ANTENNAGATEAREA and ANTENNA*CAR statements for the pin that follow it until you specify another ANTENNAMODEL statement. The ANTENNAMODEL statement does not affect ANTENNAPARTIAL*AREA and ANTENNADIFFAREA statements because they refer to the total metal, cut, or diffusion area connected to the pin, and do not vary with each oxide model.
Default: OXIDE1, for a new PIN statement

Because LEF is often used incrementally, if an ANTENNA statement occurs twice for the same oxide model, the last value specified is used.

For most standard cells, there is only one value for the ANTENNAPARTIAL*AREA and ANTENNADIFFAREA values per pin; however, for a block with six routing layers, it is possible to have six different ANTENNAPARTIAL*AREA values and six different ANTENNAPINDIFFAREA values per pin. It is also possible to have six different ANTENNAPINGATEAREA and ANTENNAPINMAX*CAR values for each oxide model on each pin.

Example 1-12 Pin Antenna Model

The following example describes oxide model information for pins IN1 and IN2.

MACRO GATE1 
PIN IN1 
ANTENNADIFFAREA 1.0 ;             #not affected by ANTENNAMODEL
...
ANTENNAMODEL OXIDE1 ;        #OXIDE1 not required, but is good
                             #practice
ANTENNAGATEAREA 1.0 ;             #OXIDE1 gate area
ANTENNAMAXAREACAR 50.0 LAYER m1 ; #metal1 CAR value 
...
ANTENNAMODEL OXIDE2 ;             #OXIDE2 starts here
ANTENNAGATEAREA 3.0 ;             #OXIDE2 gate area
...
PIN IN2
ANTENNADIFFAREA 2.0 ;             #not affected by ANTENNAMODEL
ANTENNAPARTIALMETALAREA 2.0 LAYER m1 ;
...
#no OXIDE1 specified for this pin
ANTENNAMODEL OXIDE2 ;
ANTENNAGATEAREA 1.0 ;
...

ANTENNAPARTIALCUTAREA value [LAYER layerName]

Specifies the partial cut area above the current pin layer and inside the macro cell on the layer. For a hierarchical design, only the cut layer above the I/O pin layer is needed for partial antenna ratio calculation. If you do not specify a layer name, the value applies to all layers.

For more information on process antenna calculation, see Appendix C, “Calculating and Fixing Process Antenna Violations.”

ANTENNAPARTIALMETALAREA value [LAYER layerName]

Specifies the partial metal area connected directly to the I/O pin and the inside of the macro cell on the layer. For a hierarchical design, only the same metal layer as the I/O pin, or the layer above it, is needed for partial antenna ratio calculation. If you do not specify a layer name, the value applies to all layers.

For more information on process antenna calculation, see Appendix C, “Calculating and Fixing Process Antenna Violations.”

Note: Metal area is calculated by adding the pin’s geometric metal area and the ANTENNAPARTIALMETALAREA value.

ANTENNAPARTIALMETALSIDEAREA value [LAYER layerName]

Specifies the partial metal side wall area connected directly to the I/O pin and the inside of the macro cell on the layer. For a hierarchical design, only the same metal layer as the I/O pin or the layer above is needed for partial antenna ratio calculation. If you do not specify a layer name, the value applies to all layers.

For more information on process antenna calculation, see Appendix C, “Calculating and Fixing Process Antenna Violations.”

DIRECTION {INPUT | OUTPUT [TRISTATE] | INOUT | FEEDTHRU}
Specifies the pin type. Most current tools do not usually use this keyword. Typically, pin directions are defined by timing library data, and not from LEF.
Default: INPUT Value: Specify one of the following:  

INPUT

Pin that accepts signals coming into the cell.

OUTPUT [TRISTATE]

Pin that drives signals out of the cell. The optional TRISTATE argument indicates tristate output pins for ECL designs.

INOUT

Pin that can accept signals going either in or out of the cell.

FEEDTHRU

Pin that goes completely across the cell.

GROUNDSENSITIVITY groundPinName

Specifies that if this pin is connected to a tie-low connection (such as 1’b0 in Verilog), it should connect to the same net to which groundPinName is connected.

groundPinName must match a pin on this macro that has a USE GROUND attribute. The ground pin definition can follow later in this MACRO statement; it does not have to be defined before this pin definition. For an example, see Example 1-13.

Note: GROUNDSENSITIVITY is useful only when there is more than one ground pin in the macro. By default, if there is only one USE GROUND pin, then the tie-low connections are already implicitly defined (that is, tie-low connections are connected to the same net as the one ground pin).

MUSTJOIN pinName

Specifies the name of another pin in the cell that must be connected with the pin being defined. MUSTJOIN pins provide connectivity that must be made by the router. In the LEF file, each pin referred to must be defined before the referring pin. The remaining MUSTJOIN pins in the set do not need to be defined contiguously.

Note: MUSTJOIN pin names are never written to the DEF file; they are only used by routers to add extra connection points during routing.

MUSTJOIN pins have the following restrictions:

Schematic and nonschematic MUSTJOIN pins are handled in slightly different ways. For schematic MUSTJOIN pins, the pins are added to the pin set for the (unique) net associated with the ring for each component instance of the macro. The net is routed in the usual manner, and routing data for the MUSTJOIN pins are included in routing data for the net.

The mustjoin routing is not necessarily performed before the rest of the net. Timing relations should not be given for MUSTJOIN pins, and internal mustjoin routing is modeled as lumped capacitance at the schematic pin.

Nonschematic MUSTJOIN pin sets get routed in the usual manner. However, when the DEF file is outputted, routing data is reported in the NETS section of the file as follows:

        MUSTJOIN compName pinName + regularWiring ;

Here, compName is the component and pinName is an arbitrary pin in the set. You can also use the preceding to input prewiring for the MUSTJOIN pin, using FIXED or COVER.

NETEXPR "netExprPropName defaultNetName"

Specifies a net expression property name (such as power1 or power2) and a default net name. If netExprPropName matches a net expression property in the netlist (such as in Verilog, VHDL, or OpenAccess), then the property is evaluated, and the software identifies a net to which to connect this pin. If this property does not exist, defaultNetName is used for the net name.

netExprPropName must be a simple identifier in order to be compatible with other languages, such as Verilog and CDL. Therefore, it can only contain alphanumeric characters, and the first character cannot be a number. For example, power2 is a legal name, but 2power is not. You cannot use characters such as $ and !. The defaultName can be any legal DEF net name.

Example 1-13 Net Expression and Supply Sensitivity

The following statement defines sensitivity and net expression values for four pins on the macro myMac:

MACRO myMac 
...
PIN in1
...
SUPPLYSENSITIVITY vddpin1 ; #If in1 is 1’b1, use net connected to vddpin1.
#Note that no GROUNDSENSITIVITY is needed
#because only one ground pin exists.
#Therefore, 1’b0 implicitly means net from
#pin gndpin.
...
END in1
PIN vddpin1
...
NETEXPR "power1 VDD1" ; #If power1 net expression is defined in the 
#netlist, use it to find the net connection. If
#not, use net VDD1.
...
END vddpin1
PIN vddpin2 
...
NETEXPR "power2 VDD2" ; #If power2 net expression is defined in the 
#netlist, use it to find the net connection.If
#not, use net VDD2.
...
END vddpin2
PIN gndpin 
...
NETEXPR "gnd1 GND" ; #If gnd1 net expression is defined in the
#netlist, use it to find the net connection. If
#not, use net GND.
...
END gndpin
...
END myMac

PIN pinName

Specifies the name for the library pin.

PORT

Starts a pin port statement that defines a collection of geometries that are electrically equivalent points (strongly connected). A pin can have multiple ports. Each PORT of the same PIN is considered weakly connected to the other PORTs, and should already be connected inside the MACRO (often through a resistive path).

Strongly connected shapes (that is, multiple shapes of one PORT) indicate that a signal router is allowed to connect to one shape of the PORT, and continue routing from another shape of the same PORT.

Weakly connected shapes (that is, separate PORTs of the same PIN) are assumed to be connected through resistive paths inside the MACRO that should not be used by routers. The signal router should connect to one or the other PORT, but not both.

Power routers should connect to every PORT statement, if there is more than one for a given PIN. For example, if a block has several PORTs on the boundary for the VSS PIN, each PORT should be connected by the power router.

The syntax for describing pin port statements is defined as follows:

{PORT [CLASS {NONE | CORE | BUMP} ;] {layerGeometries} ... END} ...

CLASS {NONE | CORE | BUMP}

Specifies the port type.
Default: NONE

A port can be one of the following:

BUMP—Specifies the port is a bump connection point. A bump port should only be connected by routing to a bump (normally a MACRO CLASS COVER BUMP cell).

CORE—Specifies the port is a core ring connection point. A core port is used only on power and ground I/O drivers used around the periphery. The core port indicates which power or ground port to connect to a core ring for the chip (inside the I/O pads).

NONE—Specifies the port is a default port that is connected by normal “default” routing. NONE is the default value if no PORT CLASS statement is specified.

layerGeometries

Defines port geometries for the pin. You specify port geometries using layer geometries syntax. See “Layer Geometries” for syntax information.

PROPERTY propName propVal

Specifies a numerical or string value for a pin property defined in the PROPERTYDEFINITIONS statement. The propName you specify must match the propName listed in the PROPERTYDEFINITIONS statement.

SHAPE

Specifies a pin with special connection requirements because of its shape.
Value: Specify one of the following:  

ABUTMENT

Pin that goes straight through cells with a regular shape and connects to pins on adjoining cells without routing.

RING

Pin on a large block that forms a ring around the block to allow connection to any point on the ring. Cover macro special pins also typically have shape RING.

FEEDTHRU

Pin with an irregular shape with a jog or neck within the cell.

Figure 1-54 shows an example of an abutment and a feedthrough pin.

When you define feedthrough and abutment pins for use with power routing, you must do the following:
  • Feedthrough pin widths must be the same on both edges and consistent with the routing width used with the power route commands.
  • Feedthrough pin centers on both edges must align for successful routing.
  • Power pins in fork shapes must be represented in two ports and be defined as a feedthrough shape. In most other cases, power pin geometries do not represent more than one port.
  • An abutment pin must have at least one geometric rectangle with layer and width consistent with the values specified in the power route commands.

Figure 1-55

SUPPLYSENSITIVITY powerPinName

Specifies that if this pin is connected to a tie-high connection (such as 1’b1 in Verilog), it should connect to the same net to which powerPinName is connected.

powerPinName must match a pin on this macro that has a USE POWER attribute. The power pin definition can follow later in this MACRO statement; it does not have to be defined before this pin definition. For an example, see Example 1-13.

Note: SUPPLYSENSITIVITY is useful only when there is more than one power pin in the macro. By default, if there is only one USE POWER pin, then the tie-high connections are already implicitly defined (that is, tie-high connections are connected to the same net as the one power pin).

TAPERRULE ruleName

Specifies the nondefault rule to use when tapering wires to the pin.

USE {ANALOG | CLOCK | GROUND | POWER | SIGNAL}

Specifies how the pin is used. Pin use is required for timing analysis. Default: SIGNAL Value: Specify one of the following:

ANALOG

Pin is used for analog connectivity.

CLOCK

Pin is used for clock net connectivity.

GROUND

Pin is used for connectivity to the chip-level ground distribution network.

POWER

Pin is used for connectivity to the chip-level power distribution network.

SIGNAL

Pin is used for regular net connectivity.

Access Area Rule

The access area rule can be used to specify a via access area on the specified cut layer.

You can specify the access area rule by using the following property definition:
PROPERTY LEF58_ACCESSAREA
   "ACCESSAREA {LAYER layerName RECT pt pt [CUTCLASS className]
   [EXCEPTEXTRACUT]}...
   ; " ;

Where:

ACCESSAREA {LAYER layerName RECT pt pt }...

Specifies a via access area on layerName, which must be a cut layer. All the cuts of a via connected to any pin shape on the bottom metal layer that overlaps the given area in RECT must be inside the given area. If there are multiple via access areas overlapping a pin shape, all the cuts of a via connected to the pin need to be inside one of the areas. Different via access areas should not overlap or be abutted. For a MUSTJOINALLPORTS pin, the given area must overlap with all of the pin shapes on the bottom metal layer. Then, the cuts on each of the individual pin shapes must be inside the given area and must be connected by a same-metal wire on the above metal layer as well. This construct can only be defined on standard cells with MACRO CLASS of CORE.
If a pin has ACCESSAREA, the ACCESSAREA defined in MACRO has no meaning on that pin. In other words, the ACCESSAREA defined in MACRO is applied only on pins without their own ACCESSAREA. Actually, tools are not likely to support overlap of pin-based and macro/cell-based access areas.
Type: Float, specified in microns

CUTCLASS className

Specifies the via access area for the given className, which is connected to the pin shapes. Without CUTCLASS, the via access area would be applied to vias of any cut class. Multiple via access areas could be defined for different cut classes. If a cut class does not have a corresponding via access area defined, the vias of that cut class could be connected to the pins without any restriction.
Type: String

EXCEPTEXTRACUT

Specifies that the via access area is not applied to vias with multiple cuts connected to a single pin shape. If a via pillar with multiple wires on the above metal layer of the pin shape layer is used, this via access area does not need to be honored. For example, if a via pillar with 2x2 cuts is connected to a MUSTJOINALLPORTS with two pin shapes, this via access area could be ignored.

Access Area Rule Example

Antenna Diff Area Rule

The antenna diff area rule can be used to specify the diffusion area to which the pin is connected on a layer.

You can specify the antenna diff area rule by using the following property definition:
PROPERTY LEF58_ANTENNADIFFAREA
   "ANTENNADIFFAREA [BACKSIDE][PROTECTOR] value [LAYER layerName]
   ; ..." ;

Where:

ANTENNADIFFAREA value [LAYER layerName]

Specifies the diffusion (diode) area, in micron-squared units, to which the pin is connected on a layer. If you do not specify a layer name, the value applies to all layers.

BACKSIDE

Specifies that the diffusion area applies only for the metal on layers with BACKSIDE.

PROTECTOR

Specifies the diffusion area for protected devices. If the metal is electrically connected to a pin defined with protector diffusion, ANTENNADIFFPROTECTORAREARATIO would only be checked. Both gate and non-protector diffusion would be ignored for other ANTENNA* rules.

Must Join All Ports Rule

You can use the must join all ports rule to specify that all ports must be connected individually.

You can create a must join all ports rule by using the following property definition:

PROPERTY LEF58_MUSTJOINALLPORTS
       “MUSTJOINALLPORTS
       ; “ ;

Where:

MUSTJOINALLPORTS

Specifies that all of the ports must be connected individually. If there are multiple shapes per ports, at least one of the shapes of the port needs to be connected. However, tools typically would connect to only one of the shapes.

For example:
PIN A

...

PROPERTY LEF58_MUSTJOINALLPORTS “

   MUSTJOINALLPORTS ; “ ;

PORT

LAYER M1 ;

RECT 1 1 2 2 ;

RECT 4 4 5 5 ;

   END

PORT

LAYER M2 ;

RECT 2 2 3 3 ;

    END

...

END A

means that the router must connect to at least one of the two M1 shapes and to the M2 shape individually. However, tools typically would connect to exactly one of the two M1 shapes and to the M2 shape individually.

Via In Must Join Rule

You can create a via in must join rule by using the following property definition:

PROPERTY LEF58_VIAINMUSTJOIN
       “VIAINMUSTJOIN
       ; “ ;

Where:

VIAINMUSTJOIN

Specifies that two stacked vias must be used to connect to the must-join pins and all of the cuts of these two stacked vias must be within the boundary box of the must-join pins. For example, if the must-join pins have multiple M1 shapes, the cuts of the stacked vias to M3 must be within the boundary box formed by the M1 pin shapes.

Via In Pin Only Rule

You can use the via in pin only rule to specify that vias must be dropped inside the original pin shapes to connect to the pin.

You can create a via in pin only rule by using the following property definition:

PROPERTY LEF58_VIAINPINONLY
“VIAINPINONLY
; ” ;

Where:

VIAINPINONLY

Specifies that at least one cut of a via must be dropped inside the original pin shapes to connect to the pin, and a planar connection to the pin is not allowed. In some advanced nodes, the pin shapes can be extended for metal alignment purpose. For a single-cut via, it means that the cut would be in the original pin shapes. For a multiple-cut via, particularly with the via pillar having multiple fingers, only one cut needs to be in the original pin shapes and the rest of the via pillar structure can be outside the original pin shapes.
To support negative enclosure, for a square cut with size CS greater than the minimum width W on the below or above metal layer of a pin shape, the following method is used to determine whether the cut is inside the pin shape. From the cut center, extend CS/2 on any two opposite sides and W/2 on the other two opposite sides, if one of the two expanded sizes (one for extending CS/2 horizontally and another for extending CS/2 vertically) is completely covered by the pin metal shape, the cut is considered to be inside the pin shape.

Manufacturing Grid

[MANUFACTURINGGRID value ;]

Defines the manufacturing grid for the design. The manufacturing grid is used for geometry alignment. When specified, shapes and cells are placed in locations that snap to the manufacturing grid.

value

Specifies the value for the manufacturing grid, in microns. value must be a positive number.
Type: Float

Maximum Via Stack

[MAXVIASTACK value [RANGE bottomLayer topLayer] ;]

Specifies the maximum number of single-cut stacked vias that are allowed on top of each other (that is, in one continuous stack). A via is considered to be in a stack with another via if the cut of the first via overlaps any part of the cut of the second via. A double-cut or larger via interrupts the stack. For example, a via stack consisting of single via12, single via23, double-cut via34, and single via45 has a single-cut stack of height 2 for via12 and via23, and a single-cut stack of height 1 for via45 because the full stack is broken up by double-cut via34.

The MAXVIASTACK statement should follow the LAYER statements in the LEF file; however, it is not attached to any particular layer. You can specify only one MAXVIASTACK statement in a LEF file.

RANGE bottomLayer topLayer

Specifies a range of layers for which the maximum stacked via rule applies. If you do not specify a range, the value applies for all layers.

value

Specifies the maximum allowed number of single-cut stacked vias.
Type: Integer

Example 1-14 Maximum Via Stack Statement

The following MAXVIASTACK statement specifies that only four stacked vias are allowed on top of each other. This rule applies to all layers.

LAYER metal9 
...
END LAYER
MAXVIASTACK 4 ;

If you specify the following statement instead, the stacked via limit applies only to layers metal1 through metal7.

MAXVIASTACK 4 RANGE m1 m7 ;

Nondefault Rule

[NONDEFAULTRULE ruleName 
[HARDSPACING ;]
{LAYER layerName
   WIDTH width ;
   [DIAGWIDTH diagWidth ;]
   [SPACING minSpacing ;] 
   [WIREEXTENSION value ;]
END layerName} ...
[VIA viaStatement] ...
[USEVIA viaName ;] ...
[USEVIARULE viaRuleName ;] ...
[MINCUTS cutLayerName numCuts ;] ...
[PROPERTY propName propValue ;] ...
[PROPERTY LEF58_USEVIACUTCLASS 
“USEVIACUTCLASS cutLayerName className
   [ROWCOL numCutRows numCutCols]
   ;... “ ;]
END ruleName] 

Defines the wiring width, design rule spacing, and via size for regular (signal) nets. You do not need to define cut layers for the non-default rule.

Some tools have limits on the total number of non-default rules they can store. This limit can be as low as 30; however most tools that support 90 nanometer rules (that is, LEF 5.5 and newer) can handle at least 255.

Use the VIA statement to define vias for non-default wiring.

DIAGWIDTH diagWidth

Specifies the diagonal width for layerName, when 45-degree routing is used.
Default: The minimum width value (WIDTH minWidth)
Type: Float, specified in microns

HARDSPACING

Specifies that any spacing values that exceed the LEF LAYER spacing requirements are “hard” rules instead of “soft” rules. By default, routers treat extra spacing requirements as soft rules that are high cost to violate, but not real spacing violations. However, in certain situations, the extra spacing should be treated as a hard, or real, spacing violation, such as when the route will be modified with a post-process that replaces some of the extra space with metal.

LAYER layerName ... END layerName

Specifies the layer for the various width and spacing values. This layer must be a routing layer. Every routing layer must have a WIDTH keyword and value specified. All other keywords are optional.

MINCUTS cutLayerName numCuts

Specifies the minimum number of cuts allowed for any via using the specified cut layer. Routers should only use vias (generated or predefined fixed vias) that have at least numCuts cuts in the via.
Type: (numCuts) Positive integer

NONDEFAULTRULE ruleName

Specifies a name for the new routing rule. The name DEFAULT is reserved for the default routing rule used by most nets. The default routing rule is constructed automatically from the LEF LAYER statement WIDTH, DIAGWIDTH, SPACING, and WIREEXTENSION values, from the LEF VIA statement (any vias with the DEFAULT keyword), and from the LEF VIARULE statement (any via rules with the DEFAULT keyword). If you specify DEFAULT for ruleName, the automatic creation is overridden, and the default routing rule is defined directly from this rule definition.

PROPERTY propName propValue

Specifies a numerical or string value for a non-default rule property defined in the PROPERTYDEFINITIONS statement. The propName you specify must match the propName listed in the PROPERTYDEFINITIONS statement.

SPACING minSpacing

Specifies the recommended minimum spacing for layerName of routes using this NONDEFAULTRULE to other geometries. If the spacing is given, it must be at least as large as the foundry minimum spacing rules defined in the LAYER definitions. Routers should attempt to meet this recommended spacing rule; however, the spacing rule can be relaxed to the foundry spacing rules along some parts of the wire if the routing is very congested, or if it is difficult to reach a pin.

Adding extra space to a non-default rule allows a designer to reduce cross-coupling capacitance and noise, but a clean route with no actual foundry spacing violations will still be allowed, unless the HARDSPACING statement is specified.
Type: Float, specified in microns

USEVIA viaName

Specifies a previously defined via from the LEF VIA statement, or a previously defined NONDEFAULTRULE via to use with this routing rule.
Applications may treat USEVIA as a soft constraint by putting the given vias on the list of target vias to be used, and they may have a separate option to specify a hard constraint for vias.

USEVIARULE viaRuleName

Specifies a previously defined VIARULE GENERATE rule to use with this routing rule. You cannot specify a rule from a VIARULE without a GENERATE keyword.

VIA viaStatement

Defines a new via. You define non-default vias using the same syntax as default vias. For syntax information, see “Via”. All vias, default and non-default, must have unique via names. If you define more than one via for a rule, the router chooses which via to use.

Note: Defining a new via is no longer recommended, and is likely to become obsolete. Instead, vias should be predefined in a LEF VIA statement, then added to the non-default rule using the USEVIA keyword.

WIDTH width

Specifies the required minimum width for layerName.
Type: Float, specified in microns

WIREEXTENSION value

Specifies the distance by which wires are extended at vias. Enter 0 (zero) to specify no extension. Values other than 0 must be greater than or equal to half of the routing width for the layer, as defined in the non-default rule.
Default: Wires are extended half of the routing width
Type: Float, specified in microns

The WIREEXTENSION statement only extends wires and not vias. For 65nm and below, WIREEXTENSION is no longer recommended because it may generate some advance rule violations if wires and vias have different widths. See Illustration of WIREEXTENSION.

Example 1-15 Nondefault Rule Statement

Assume two default via rules were defined:

VIARULE via12rule GENERATE DEFAULT
LAYER metal1 ;
...
END via12rule
VIARULE via23rule GENERATE DEFAULT
LAYER metal2 ;
...
END via23rule
NONDEFAULTRULE wide1_5x
LAYER metal1
WIDTH 1.5 ; #metal1 has a 1.5 um width
END metal1
LAYER metal2 
WIDTH 1.5 ;
END metal2
LAYER metal3 
WIDTH 1.5 ;
END metal3
END wide1_5x
If there were no default via rules, then a VIA, USEVIA, or USEVIARULE keyword would be required. Because there are none defined, the default via rules are implicitly inherited for this non-default rule; therefore, via12rule and via23rule would be used for this routing rule.
NONDEFAULTRULE wide3x
LAYER metal1
WIDTH 3.0 ; #metal1 has 3.0 um width
END metal1
LAYER metal2 
WIDTH 3.0 ;
END metal2 
LAYER metal3 
WIDTH 3.0 ;
END metal3
#viarule12 and viarule23 are used implicitly
MINCUTS cut12 2 ; #at least two-cut vias are required for cut12
MINCUTS cut23 2 ;
END wide3x
NONDEFAULTRULE analog_rule
HARDSPACING ;     #do not let any other signal close to this one
LAYER metal1
WIDTH 1.5 ;   #metal1 has 1.5 um width
SPACING 3.0 ; #extra spacing of 3.0 um
END metal1
LAYER metal2 
WIDTH 1.5
SPACING 3.0
END metal2
LAYER metal3 
WIDTH 1.5
SPACING 3.0
END metal3
#Use predefined "analog vias"
#The DEFAULT VIARULES will not be inherited. 
USEVIA via12_fixed_analog_via ;
USEVIA via_23_fixed_analog_via ;
END analog_rule

Use Via Cut Class Rule

You can use the use via cut class only rule to specify the cut class to be used with the routing rule.

You can create a use via cut class rule by using the following property definition:

PROPERTY LEF58_USEVIACUTCLASS
USEVIACUTCLASS cutLayerName className
   [ROWCOL numCutRows numCutCols]
   ;... “ ;

Where:

USEVIACUTCLASS cutLayerName className [ROWCOL numCutRows numCutCols]

Specifies className cuts on cutLayerName, which must be a cut layer, to be used with this routing rule. ROWCOL specifies the number of cut rows and columns of a multiple-cut via of the cut class className to be used with this routing rule. By default, a single cut via or the given cut number defined in MINCUTS is used.
Applications may treat USEVIACUTCLASS as a hard constraint and apply the given cut class vias on the non-default rule.

Property Definitions

[PROPERTYDEFINITIONS 
[objectType propName propType [RANGE min max] 
   [value | "stringValue"] 
;] ...
END PROPERTYDEFINITIONS]

Lists all properties used in the LEF file. You must define properties in the PROPERTYDEFINITIONS statement before you can refer to them in other sections of the LEF file.

objectType

Specifies the object type being defined. You can define properties for the following object types:

LAYER

LIBRARY

MACRO

NONDEFAULTRULE

PIN

VIA

VIARULE

propName

Specifies a unique property name for the object type.

propType

Specifies the property type for the object type. You can specify one of the following property types:

INTEGER

REAL

STRING

RANGE min max

Limits real number and integer property values to a specified range. That is, the value must be greater than or equal to min and less than or equal to max.

value | "stringValue"

Assigns a numeric value or a name to a LIBRARY object type.

Note: Assign values to other properties in the section of the LEF file that describes the object to which the property applies.

Example 1-16 Property Definitions Statement

The following example shows library, via, and macro property definitions.

PROPERTYDEFINITIONS
LIBRARY versionNum INTEGER 12;
LIBRARY title STRING "Cadence96";
VIA count INTEGER RANGE 1 100;
MACRO weight REAL RANGE 1.0 100.0;
MACRO type STRING;
END PROPERTYDEFINITIONS

Site

SITE siteName
CLASS {PAD | CORE} ;
[SYMMETRY {X | Y | R90} ... ;]
[ROWPATTERN {previousSiteName siteOrient} ... ;]
SIZE width BY height ;
END siteName 

Defines a placement site in the design. A placement site gives the placement grid for a family of macros, such as I/O, core, block, analog, digital, short, tall, and so forth. SITE definitions can be used in DEF ROW statements.

CLASS {PAD | CORE}

Specifies whether the site is an I/O pad site or a core site.

ROWPATTERN {previousSiteName siteOrient}

Specifies a set of previously defined sites and their orientations that together form siteName. The height of each previously defined site must be the same as the height specified for siteName, and the sum of the widths of the previously defined sites is equal to the width specified for siteName.

previousSiteName

Specifies the name of a previously defined site. The sites in previousSiteName have to be basic sites with no pattern.

siteOrient

Specifies the orientation for the previously defined site. This value must be one of N, S, E, W, FN, FS, FE, and FW. For more information on orientations, see “Specifying Orientation” in the DEF COMPONENT section.

SITE siteName

Specifies the name for the placement site.

SIZE width BY height

Specifies the dimensions of the site in normal (or north) orientation, in microns.

SYMMETRY {X | Y | R90}

Indicates which site orientations are equivalent. The sites in a given row all have the same orientation as the row. Generally, site symmetry should be used to control the flipping allowed inside the rows. For more information on defining symmetry, see “Defining Symmetry”.

Possible orientations include:

X

Site is symmetric about the x axis. This means that N and FS sites are equivalent, and FN and S sites are equivalent. A macro with an orientation of N matches N or FS rows.

Y

Site is symmetric about the y axis. This means that N and FN sites are equivalent, and FS and S sites are equivalent. A macro with an orientation of N matches N or FN rows.

X Y

Site is symmetric about the x and y axis. This means that N, FN, FS, and S sites are equivalent. A macro with orientation N matches N, FN, FS, or S rows.

R90

Site is symmetric when rotated 90 degrees. Typically, this value is not used.

Typically, a site for single-height standard cells uses symmetry Y, and a site for double-height standard cells uses symmetry X Y.

Example 1-17 Site Row Pattern

The following example defines three sites: Fsite; Lsite; and mySite, which consists of a pattern of Fsite and Lsite sites:

SITE Fsite
CLASS CORE ;
SIZE 4.0 BY 7.0 ; #4.0 um width, 7.0 um height
END Fsite
SITE Lsite
CLASS CORE ;
SIZE 6.0 BY 7.0 ; #6.0 um width, 7.0 um height
END Lsite
SITE mySite
ROWPATTERN Fsite N Lsite N Lsite FN ; #Pattern of F + L + flipped L
SIZE 16.0 BY 7.0 ;                    #Width = width(F + L + L)
END mySite

The figure below illustrates some DEF rows made up of mySite sites.

Figure 1-57 Site Row Pattern Example

Units

[UNITS 
[TIME NANOSECONDS convertFactor ;]
[CAPACITANCE PICOFARADS convertFactor ;]
[RESISTANCE OHMS convertFactor ;]
[POWER MILLIWATTS convertFactor ;]
[CURRENT MILLIAMPS convertFactor ;]
[VOLTAGE VOLTS convertFactor ;]
[DATABASE MICRONS LEFconvertFactor ;]
[FREQUENCY MEGAHERTZ convertFactor ;]
END UNITS]

Defines the units of measure in LEF. The values tell you how to interpret the numbers found in the LEF file. Units are fixed with a convertFactor for all unit types, except database units and capacitance. For more information, see “Convert Factors”. Currently, other values for convertFactor appearing in the UNITS statement are ignored.

The UNITS statement is optional and, when used, must precede the LAYER statements.

CAPACITANCE PICOFARADS convertFactor

Interprets one LEF capacitance unit as 1 picofarad.

CURRENT MILLIAMPS convertFactor

Interprets one LEF current unit as 1 milliamp.

DATABASE MICRONS LEFconvertFactor

Interprets one LEF distance unit as multiplied when converted into database units.

If you omit the DATABASE MICRONS statement, a default value of 100 is recorded as the LEFconvertFactor in the database. In this case, one micron would equal 100 database units.

FREQUENCY MEGAHERTZ convertFactor

Interprets one LEF frequency unit as 1 megahertz.

POWER MILLIWATTS convertFactor

Interprets one LEF power unit as 1 milliwatt.

RESISTANCE OHMS convertFactor

Interprets one LEF resistance unit as 1 ohm.

TIME NANOSECONDS convertFactor

Interprets one LEF time unit as 1 nanosecond.

VOLTAGE VOLTS convertFactor

Interprets one LEF voltage unit as 1 volt.

Database Units Information

Database precision is relative to Standard International (SI) units. LEF values are converted to integer values in the library database as follows.

SI unit Database precision

1 nanosecond

= 1,000 DBUs

1 picofarad

= 1,000,000 DBUs

1 ohm

= 10,000 DBUs

1 milliwatt

= 10,000 DBUs

1 milliamp

= 10,000 DBUs

1 volt

= 1,000 DBUs

Convert Factors

LEF supports values of 100, 200, 400, 800, 1000, 2000, 4000, 8000, 10,000, and 20,000 for LEFconvertFactor. The following table illustrates the conversion of LEF distance units into database units.

LEFconvertFactor LEF Database Units

100

1 micron

100

200

1 micron

200

400

1 micron

400

800

1 micron

800

1000

1 micron

1000

2000

1 micron

2000

4000

1 micron

4000

8000

1 micron

8000

10,000

1 micron

10,000

20,000

1 micron

20,000

The DEF database precision cannot be more precise than the LEF database precision. This means the DEF convert factor must always be less than or equal to the LEF convert factor. The LEF convert factor must also be an integer multiple of the DEF convert factor so no round-off of DEF database unit values is required (e.g., a LEF convert factor of 1000 allows DEF convert factors of 100, 200, 1000, but not 400, 800). The following table shows the valid pairings of the LEF convert factor and the corresponding DEF convert factor.  

LEFconvertFactor Legal DEFconvertFactors

100

100

200

100, 200

400

100, 200, 400

800

100, 200, 400, 800

1000

100, 200, 1000

2000

100, 200, 400, 1000, 2000

4000

100, 200, 400, 800, 1000, 2000, 4000

8000

100, 200, 400, 800, 1000, 2000, 4000, 8000

10,000

100, 200, 400, 1000, 2000, 10,000

20,000

100, 200, 400, 800, 1000, 2000, 4000, 10,000, 20,000

An incremental LEF should have the same value as a previous LEF. An error message warns you if an incremental LEF has a different value than what is recorded in the database.

Use Min Spacing

[USEMINSPACING OBS { ON | OFF } ;]

Defines how minimum spacing is calculated for obstruction (blockage) geometries.

OBS {ON | OFF}

Specifies how to calculate minimum spacing for obstruction geometries (MACRO OBS shapes).
Default: ON

OFF

Spacing is computed to MACRO OBS shapes as if they were actual routing shapes. A wide OBS shape would use wide wire spacing rules, and a thin OBS shapes would use thin wire spacing rules.

ON

Spacing is computed as if the MACRO OBS shapes were min-width wires. Some LEF models abstract many min-width wires as a single large OBS shape; therefore using wide wire spacing would be too conservative.

OFF is the recommended value to specify because it is a better abstract model for the various wide wire spacing rules that are more common at process nodes of 130nm and smaller. Certain older style LEF abstracts use ON, but it can have unexpected side effects (such as hidden DRC errors) if the abstracts are not created very carefully. You cannot mix both types of LEF abstracts at the same time.

Version

VERSION number ;

Specifies which version of the LEF syntax is being used. number is a string of the form major.minor[.subMinor], such as 5.8.

Many applications default to the latest version of LEF/DEF supported by the application (which depends on how old the application is). The latest version as described by this document is 5.8. However, a default value of 5.8 is not formally part of the language definition; therefore, you cannot be sure that all applications use this default value. Also, because the default value varies with the latest version, you should not depend on this.

Via

VIA viaName [DEFAULT] 
{ VIARULE viaRuleName ;
     CUTSIZE xSize ySize ;
     LAYERS botMetalLayer cutLayer topMetalLayer ;
     CUTSPACING xCutSpacing yCutSpacing ; 
     ENCLOSURE xBotEnc yBotEnc xTopEnc yTopEnc ;
     [ROWCOL numCutRows numCutCols ;] 
     [ORIGIN xOffset yOffset ;] 
     [OFFSET xBotOffset yBotOffset xTopOffset yTopOffset ;] 
     [PATTERN cutPattern ;]
} 
| {[RESISTANCE resistValue ;]
   {LAYER layerName ; 
     { RECT [MASK maskNum] pt pt ;
     | POLYGON [MASK maskNum] pt pt pt ...;} ...
   } ... 
  }
[PROPERTY propName propVal ;] ...
END viaName 

Defines two types of vias: fixed vias and generated vias. All vias consist of shapes on three layers: a cut layer and two routing (or masterslice) layers that connect through that cut layer.

A LEF fixed via is defined using rectangles or polygons, and does not use a VIARULE. The fixed via name must mean the same via in all associated LEF and DEF files.

A LEF generated via is defined using VIARULE parameters to indicate that it was derived from a VIARULE GENERATE statement. The parameterized via name must mean the same via in all LEF files.

Note that unlike LEF, a DEF parameterized VIA can have its name changed as long as the parameters are kept the same (see DEF Vias section), but LEF VIAs are assumed to be “common library data” that can be used by other LEF files, such as LEF MACROs, so all LEF VIA definition names should be defined only once in all the LEF files that are loaded.

If a LEF MACRO block needs its own locally defined VIA definition that is not already defined, it should use a unique via name. One way to do so is to use the MACRO name in the VIA definition name. For example, MACRO my_block1 might have a unique via named VIA my_block1_via1 inside the same LEF file.

CUTSIZE xSize ySize

Specifies the required width (xSize) and height (ySize) of the cut layer rectangles.
Type: Float, specified in microns

CUTSPACING xCutSpacing yCutSpacing

Specifies the required x and y spacing between cuts. The spacing is measured from one cut edge to the next cut edge.
Type: Float, specified in microns

DEFAULT

Identifies the via as the default via between the defined layers. Default vias are used for default routing by the signal routers.

If you define more than one default via for a layer pair, the router chooses which via to use. You must define default vias between metal1 and masterslice layers if there are pins on the masterslice layers.

All vias consist of shapes on three layers: a cut layer and two routing (or masterslice) layers that connect through that cut layer. There should be at least one RECT or POLYGON on each of the three layers.

ENCLOSURE xBotEnc yBotEnc xTopEnc yTopEnc

Specifies the required x and y enclosure values for the bottom and top metal layers. The enclosure measures the distance from the cut array edge to the metal edge that encloses the cut array.
Type: Float, specified in microns

Note: It is legal to specify a negative number, as long as the resulting metal size is positive.

LAYER layerName

Specifies the layer on which to create the rectangles that make up the via. All vias consist of shapes on three layers: a cut layer and two routing (or masterslice) layers that connect through that cut layer. There should be at least one RECT or POLYGON on each of the three layers.

LAYERS botMetalLayer cutLayer topMetalLayer

Specifies the required names of the bottom routing (or masterslice) layer, cut layer, and top routing (or masterslice) layer. These layer names must be previously defined in layer definitions, and must match the layer names defined in the specified LEF viaRuleName.

MASK maskNum

Specifies which mask for double- or triple-patterning lithography is to be applied to the shapes defined in RECT or POLYGON of the via master. The maskNum variable must be a positive integer. Most applications only support values of 1, 2, or 3. For a fixed via made up of RECT or POLYGON statements, the cut-shapes should either be all colored or not colored at all. It is an error to have partially colored cuts for one via. Uncolored cut shapes should be automatically colored if the layer is a multi-mask layer.
The metal shapes with a shape per layer of the via-master do not need colors because the via instance has the mask color, but some readers will color them as mask 1 for internal consistency (see Figure 1-62 ). So a writer may write out MASK 1 for the metal shapes even if they are read in with no MASK value.

OFFSET xBotOffset yBotOffset xTopOffset yTopOffset

Specifies the x and y offset for the bottom and top metal layers. By default, the 0,0 origin of the via is the center of the cut array, and the enclosing metal rectangles. These values allow each metal layer to be offset independently. After the non-shifted via is computed, the metal layer rectangles are offset by adding the appropriate values—the x/y BotOffset values to the metal layer below the cut layer, and the x/ y TopOffset values to the metal layer above the cut layer. These offsets are in addition to any offset caused by the ORIGIN values.
Default: 0, for all values
Type: Float, specified in microns

ORIGIN xOffset yOffset

Specifies the x and y offset for all of the via shapes. By default, the 0,0 origin of the via is the center of the cut array, and the enclosing metal rectangles. After the non-shifted via is computed, all cut and metal rectangles are offset by adding these values.
Default: 0, for both values
Type: Float, specified in microns

PATTERN cutPattern

Specifies the cut pattern encoded as an ASCII string. This parameter is only required when some of the cuts are missing from the array of cuts, and defaults to “all cuts are present,” if not specified.

For information on and examples of via cut patterns, see Creating Via Cut Patterns.

The cutPattern syntax uses “_” as a separator, and is defined as follows:

numRows_rowDefinition
[_numRows_rowDefinition] ...

numRows

Specifies a hexadecimal number that indicates how many times to repeat the following row definition. This number can be more than one digit.

rowDefinition

Defines one row of cuts, from left to right.

The rowDefinition syntax is defined as follows:

{[RrepeatNumber]hexDigitCutPattern} ...

hexDigitCutPattern

Specifies a single hexadecimal digit that encodes a 4-bit binary value, in which 1 indicates a cut is present, and 0 indicates a cut is not present.

repeatNumber

Specifies a single hexadecimal digit that indicates how many times to repeat   hexDigitCutPattern.

For parameterized vias (with + VIARULE ...), the cutPattern has an optional suffix added to allow three types of mask color patterns. The default mask color pattern (no suffix) is a checker-board defined as an alternating pattern starting with MASK 1 at the bottom left. Then the mask cycles left-to-right, and from bottom-to-top, as shown in Figure 1-60.The other two patterns supported are alternating rows, and alternating columns, see Figure 1-61.

The optional suffixes are:

<cut_pattern>_MR alternating rows

<cut_pattern>_MC alternating columns

POLYGON pt pt pt

Specifies a sequence of at least three points to generate a polygon geometry. Most fab DRC rules require each polygon edge to be parallel to the x or y axis, or at a 45-degree angle. However, odd-angles are allowed sometimes on a few layers, such as bump layers. Each POLYGON statement defines a polygon generated by connecting each successive point, and then by connecting the first and last points.
The pt syntax corresponds to an x y coordinate pair, such as -0.2 1.0.
Type: Float, specified in microns

Example 1-18 Via Rules

The following via rule describes a non-shifted via (that is, a via with no OFFSET or ORIGIN parameters). There are two rows and three columns of via cuts. Figure 1-57 illustrates this via rule.

VIA myVia
VIARULE myViaRule ;
CUTSIZE 20 20 ;             #xCutSize yCutSize
LAYERS metal1 cut12 metal2 ;
CUTSPACING 30 30 ;           #xCutSpacing yCutSpacing
ENCLOSURE 20 50 50 20 ;      #xBotEnc yBotEnc xTopEnc yTopEnc
ROWCOL 2 3 ;
END myVia

Figure 1-58 Via Rule

The same via rule with the following ORIGIN parameter shifts all of the metal and cut rectangles by 10 in the x direction, and by -10 in the y direction (see Figure 1-58):

ORIGIN 10 -10 ;

Figure 1-59 Via Rule With Origin

If the same via rule contains the following ORIGIN and OFFSET parameters, all of the rectangles shift by 10, -10. In addition, the top layer metal rectangle shifts by 20, -20, which means that the top metal shifts by a total of 30, -30.

ORIGIN 10 -10 ;
OFFSET 0 0 20 -20 ;

Figure 1-60 Via Rule With Origin and Offset

Example 1-19 Via Polygon

The following via definition creates a polygon geometry used by X-routing applications:

VIA myVia23
LAYER metal2 ;
POLYGON -2.1 -1.0 -0.1 1.0 2.1 1.0 0.1 -1.0 ;
LAYER cut23 ;
RECT -0.4 -0.4 0.4 0.4 ;
LAYER metal3 ;
POLYGON -0.1 -1.0 -2.1 1.0 0.1 1.0 2.1 -1.0 ;
END myVia23

PROPERTY propName propVal

Specifies a numerical or string value for a via property defined in the PROPERTYDEFINITIONS statement. The propName you specify must match the propName listed in the PROPERTYDEFINITIONS statement.

RECT pt pt

Specify the corners of a rectangular shape in the via. The pt syntax corresponds to an x y coordinate pair, such as -0.4 -4.0. For vias used only in macros or pins, reference locations and rectangle coordinates must be consistent.
Type: Float, specified in microns

RESISTANCE resistValue

Specifies the lumped resistance for the via. This is not a resistance per via-cut value; it is the total resistance of the via. By default, via resistance is computed from the via LAYER RESISTANCE value; however, you can override that value with this value. resistValue is ignored if a via rule is specified, because only the VIARULE definition or a cut layer RESISTANCE value gives the resistance for generated vias.
Type: Float, specified in ohms

Note: A RESISTANCE value attached to an individual via is no longer recommended.

ROWCOL numCutRows numCutCols

Specifies the number of cut rows and columns that make up the via array.
Default: 1, for both values
Type: Positive integer, for both values

viaName

Specifies the name for the via.

VIARULE viaRulename

Specifies the name of the LEF VIARULE that produced this via. This indicates that the via is the result of automatic via generation, and that the via name is only used locally inside this LEF file. The geometry and parameters are maintained, but the name can be freely changed by applications that use this via when writing out LEF and DEF files.

viaRuleName must be specified before you define any of the other parameters, and must refer to a previously defined VIARULE GENERATE rule name. It cannot refer to a VIARULE without a GENERATE keyword.

Specifying the reserved via rule name of DEFAULT indicates that the via should use a previously defined VIARULE GENERATE rule with the DEFAULT keyword that exists for this routing-cut-routing (or masterslice-cut-masterslice) layer combination. This makes it possible for an IP block user to use existing via rules from the normal LEF technology section instead of requiring it to locally create its own via rules for just one LEF file.

Example 1-20 Generated Via Rule

The following via definition defines a generated via that is used only in this LEF file.

VIA myBlockVia
VIARULE DEFAULT ;                   #Use existing VIARULE GENERATE rule with
#the DEFAULT keyword
CUTSIZE 0.1 0.1 ;                #Cut is 0.1 x 0.1 um
LAYERS metal1 via12 metal2 ;     #Bottom metal, cut, and top metal layers
CUTSPACING 0.1 0.1 ;             #Space between cut edges is 0.1 um
ENCLOSURE 0.05 0.01 0.01 0.05 ; #metal1 enclosure is 0.05 in x, 0.01 in y
#metal2 enclosure is 0.01 in x, 0.05 in y
ROWCOL 1 2 ;                     #1 row, 2 columns = 2 cuts
END myBlockVia

Example 1-21 Parameterized via cut-mask pattern

The following example shows a VIARULE parameterized via:

VIA  myParamVia1
VIARULE myGenVia1          CUTSIZE 0.4 0.4
LAYERS M1 VIA1 M2          CUTSPACING 0.4 0.4
ENCLOSURE 0.4 0 0 0.4      ROWCOL 3 4         #3 rows, 4 columns
PATTERN 2_F_1_D;                              #1 cut in top row is missing

Example of a parameterized via checker-board cut-mask pattern for a 3-mask layer with 2 missing cuts. For parameterized vias (with VIARULE ...), the mask of the cuts are pre-defined as an alternating pattern starting with MASK 1 at the bottom left. The mask cycles from left-to-right and bottom-to-top are shown.

Figure 1-61 Parameterized via cut-mask pattern using PATTERN

Figure 1-62 Parameterized via cut-mask pattern using Suffixes

Example 1-22 Fixed-via with pre-colored cut shapes

The following example shows a fixed-via with pre-colored cut shapes:

VIA myVia1
LAYER m1 ;
RECT -0.4 -0.2 1.2 0.2 ;           #no mask, some readers will set to mask 1
LAYER via1 ;
RECT MASK 1 -0.2 -0.2 0.2 0.2 ;   #first cut on mask 1
RECT MASK 2  0.6 -0.2 1.0 0.2 ;   #second cut on mask 2
LAYER m2 ;
RECT -0.2 -0.4 1.0 0.4 ;           #no mask, some readers will set to mask 1
END myVia1

For a fixed via made up of RECT or POLYGON statements, the cut shapes must all be colored or not colored at all. If the cuts are not colored, they will be automatically colored in a checkerboard pattern as described above for parameterized vias. Each via-cut with the same lower-left Y value is considered one row, and each via in one row is a new column. For common "array" style vias with no missing cuts, this coloring is a good one. For vias that do not have a row and column structure, or are missing cuts this coloring may not be good (see Figure 1-62). If the metal layers having only one shape per layer are not colored, some applications will color them to MASK 1 for internal consistency, even though the via-master metal shape colors are not really used by LEF/DEF via instances. For multiple disjoint metal shapes, it is highly recommended to provide proper color.

Figure 1-63 Fixed-via with pre-colored cut shapes

See the MACRO Layer Geometries statement to see how a via-instance uses these via-master mask values.

Via Rule

VIARULE viaRuleName
LAYER layerName ;
   DIRECTION {HORIZONTAL | VERTICAL} ;
   [WIDTH minWidth TO maxWidth ;]
LAYER layerName ;
   DIRECTION {HORIZONTAL | VERTICAL} ;
   [WIDTH minWidth TO maxWidth ;]
{VIA viaName ;} ...
[PROPERTY propName propVal ;] ...
END viaRuleName 

Defines which vias to use at the intersection of special wires of the same net.

You should only use VIARULE GENERATE statements to create a via for the intersection of two special wires. In earlier versions of LEF, VIARULE GENERATE was not complete enough to cover all situations. In those cases, a fixed VIARULE (without a GENERATE keyword) was sometimes used. This is no longer required.

DIRECTION {HORIZONTAL | VERTICAL}

Specifies the wire direction. If you specify a WIDTH range, the rule applies to wires of the specified DIRECTION that fall within the range. Otherwise, the rule applies to all wires of the specified DIRECTION on the layer.

LAYER layerName

Specifies the routing or masterslice layers for the top or bottom of the via.

PROPERTY propName propVal

Specifies a numerical or string value for a via rules property defined in the PROPERTYDEFINITIONS statement. The propName you specify must match the propName listed in the PROPERTYDEFINITIONS statement.

VIA viaName

Specifies a previously defined via to test for the current via rule. The first via in the list that can be placed at the location without design rule violations is selected. The vias must all have exactly three layers in them. The three layers must include the same routing or masterslice layers as listed in the LAYER statements of the VIARULE, and a cut layer that is between the two routing or masterslice layers.

VIARULE viaRuleName

Specifies the name to identify the via rule.

WIDTH minWidth TO maxWidth

Specifies a wire width range. If the widths of two intersecting special wires fall within the wire width range, the VIARULE is used. To fall within the range, the widths must be greater than or equal to minWidth and less than or equal to maxWidth.

Note: WIDTH is defined by wire direction, not by layer. If you specify a WIDTH range, the rule applies to wires of the specified DIRECTION that fall within the range.

Example 1-23 Via Rule Statement

In the following example, whenever a metal1 wire with a width between 0.5 and 1.0 intersects a metal2 wire with a width between 1.0 and 2.0, the via generation code attempts to put a via12_1 at the intersection first. If the via12_1 causes a DRC violation, a via12_2 is then tried. If both fail, the default behavior from a VIARULE GENERATE statement for metal1 and metal2 is used.

VIARULE viaRule1
LAYER metal1 ;
DIRECTION HORIZONTAL ;
WIDTH 0.5 TO 1.0 ;
LAYER metal2 ;
DIRECTION VERTICAL ;
WIDTH 1.0 TO 2.0 ;
VIA via12_1 ;
VIA via12_2 ;
END viaRule1

Via Rule Generate

VIARULE viaRuleName GENERATE [DEFAULT]
LAYER routingLayerName ;
   ENCLOSURE overhang1 overhang2 ;
   [WIDTH minWidth TO maxWidth ;]
LAYER routingLayerName ;
   ENCLOSURE overhang1 overhang2 ;
   [WIDTH minWidth TO maxWidth ;]
LAYER cutLayerName ;
   RECT pt pt ;
   SPACING xSpacing BY ySpacing ;
   [RESISTANCE resistancePerCut ;]
END viaRuleName 

Defines formulas for generating via arrays. You can use the VIARULE GENERATE statement to cover special wiring that is not explicitly defined in the VIARULE statement.

Rather than specifying a list of vias for the situation, you can create a formula to specify how to generate the cut layer geometries.

Any vias created automatically from a VIARULE GENERATE rule that appear in the DEF NETS or SPECIALNETS sections must also appear in the DEF VIA section.

DEFAULT

Specifies that the via rule can be used to generate vias for the default routing rule. There can only be one VIARULE GENERATE DEFAULT for a given routing-cut-routing (or masterslice-cut-masterslice) layer combination.

Example 1-24 Via Rule Generate Default

The following example defines a rule for generating vias for the default routing or masterslice rule:

VIARULE via12 GENERATE DEFAULT
LAYER m1 ;
ENCLOSURE 0.03 0.01 ; #2 sides need >= 0.03, 2 other sides need >= 0.01
LAYER m2 ;
ENCLOSURE 0.05 0.01 ; #2 sides need >= 0.05, 2 other sides need >= 0.01
LAYER cut12 ;
RECT -0.1 -0.1 0.1 0.1 ; # cut is .20 by .20
SPACING 0.40 BY 0.40 ;   #center-to-center spacing
RESISTANCE 20 ;          #ohms per cut
END via12

ENCLOSURE overhang1 overhang2

Specifies that the via must be covered by metal on two opposite sides by at least overhang1, and on the other two sides by at least overhang2 (see Figure 1-63). The via generation code then chooses the direction of overhang that best maximizes the number of cuts that can fit in the via.

If there are also ENCLOSURE rules for the cut layer that apply to a given via, the via generation code will choose the ENCLOSURE rule with values that match the ENCLOSURE in VIARULE GENERATE. If there is no such match, the via generation code will ignore the ENCLOSURE in VIARULE GENERATE and choose which ENCLOSURE rule is best in LAYER ENCLOSURE values that apply to the same width via being generated. This means that only ENCLOSURE statements in LAYER CUT are honored, and one of them will be used.

For example, VIARULE GENERATE ENCLOSURE 0.2 0.0 combined with a LAYER CUT rule of ENCLOSURE 0.2 0.0, ENCLOSURE 0.1 0.1 and ENCLOSURE 0.15 0.15 WIDTH 0.5, would mean that any via inside a wire with width that is greater than or equal to 0.5 wide, 0.15 0.15 enclosure values are used. Otherwise, 0.2 0.0 enclosure values are used. See the LAYER CUT ENCLOSURE statement for more information on handling multiple enclosure rule.
Type: Float, specified in microns

Figure 1-64 Overhang

Example 1-25 Via Rule Generate Enclosure

The following example describes a formula for generating via cuts:

VIARULE via12 GENERATE 
LAYER m1 ;
ENCLOSURE 0.05 0.01 ; #2 sides must be >=0.05, 2 other sides must be >=0.01
WIDTH 0.2 TO 100.0 ;  #for m1, between 0.2 to 100 microns wide
LAYER m2 ; 
ENCLOSURE 0.05 0.01 ; #2 sides must be >=0.05, 2 other sides must be >=0.01
WIDTH 0.2 TO 100.0 ;  #for m2, between 0.2 to 100 microns wide
LAYER cut12
RECT -0.07 -0.07 0.07 0.07 ; #cut is .14 by .14
SPACING 0.30 BY 0.30 ;       #center-to-center spacing
END via12

The cut layer SPACING ADJACENTCUTS statement can override the VIARULE cut layer SPACING statements. For example, assume the following cut layer information is also defined in the LEF file:

LAYER cut12 
...
SPACING 0.20 ADJACENTCUTS 3 WITHIN 0.22 ;
...

The 0.20 μm edge-to-edge spacing in the ADJACENTCUTS statement is larger than the VIARULE GENERATE example spacing of 0.16 (0.30 − 0.14). Whenever the VIARULE GENERATE rule creates a via that is larger than 2x2 cuts (that is, 2x3, 3x2, 3x3 and so on), the 0.20 spacing from the ADJACENTCUTS statement is used instead.

The spacing in VIARULE GENERATE is center-to-center spacing, whereas the spacing in ADJACENTCUTS is edge-to-edge.

GENERATE

Defines a formula for generating the appropriate via.

LAYER cutLayerName

Specifies the cut layer for the generated via.

LAYER routingLayerName

Specifies the routing (or masterslice) layers for the top and bottom of the via.

RECT pt pt

Specifies the location of the lower left contact cut rectangle.

RESISTANCE resistancePerCut

Specifies the resistance of the cut layer, given as the resistance per contact cut.
Default: The resistance value in the LAYER (Cut) statement
Type: Float

SPACING xSpacing BY ySpacing

Defines center-to-center spacing in the x and y dimensions to create an array of contact cuts.The number of cuts of an array in each direction is the most that can fit within the bounds of the intersection formed by the two special wires. Cuts are only generated where they do not violate stacked or adjacent via design rules.

Note: This value can be overridden by the SPACING ADJACENTCUTS value in the cut layer statement.

VIARULE viaRuleName

Specifies the name for the rule.

The name DEFAULT is reserved and should not be used for any via rule name. In the LEF and DEF VIA definitions that use generated via parameters, the reserved DEFAULT name indicates the via rule with the DEFAULT keyword.

WIDTH minWidth TO maxWidth

Specifies a wire width range to use for this VIARULE. This VIARULE can be used for wires with a width greater than or equal to (>=) minWidth, and less than or equal to (<=) maxWidth for the given routing (or masterslice) layer. If no WIDTH statement is specified, the VIARULE can be used for all wire widths on the given routing (or masterslice) layer.


Return to top
 ⠀
X