1

---

LEF Syntax

---

This chapter contains information about the following topics:

• About Library Exchange Format Files
  • General Rules
  • Character Information
    • Name Escaping Semantics for LEF/DEF Files
  • Managing LEF Files
  • Order of LEF Statements
• LEF Statement Definitions
  • Bus Bit Characters
  • Clearance Measure
  • Divider Character
  • Extensions
  • FIXEDMASK
  • Layer (Cut)
  • Layer (Implant)
  • Layer (Masterslice or Overlap)
  • Layer (Routing)
  • Library
  • Macro
  • Macro Port or Obs Layer Geometries
  • Macro Obstruction Statement
  • Macro Pin Statement
  • Manufacturing Grid
  • Maximum Via Stack
  • Nondefault Rule
  • Property Definitions
  • Site
  • Units
  • Use Min Spacing
  • Version
  • Via
  • Via Rule
  • Via Rule Generate

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:

• Identifiers like net names and cell names are limited to 2,048 characters.
• Distance is specified in microns.
• Distance precision is controlled by the UNITS statement.
• LEF statements end with a semicolon ( ; ). You must leave a space between the last character in the statement and the semicolon.

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.

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 “tag”
extension 

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:

• LEF Syntax - Layer (Cut)

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:

• LEF Syntax - Layer (Implant)

Layer (Masterslice or Overlap)

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

• LEF Syntax - Layer (Masterslice or Overlap)

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:

• LEF Syntax - Layer (Routing)

Library

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

You can include library properties in your LEF file to create DRC rules that currently are not supported by existing LEF syntax. The properties are specified inside the PROPERTYDEFINITIONS statements.

• The property names used for these rules all start with LEF_CDN_.

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 LEF_CDN_ANTENNAMAXCUMAREA STRING ;

   LIBRARY LEF_CDN_ANTENNAMAXGATEAREA STRING ;

   LIBRARY LEF_CDN_ANTENNAMODELGROUP STRING ;

   LIBRARY LEF_CDN_CELLEDGESPACINGTABLE STRING ;

   LIBRARY LEF_CDN_CELLVARIANTS STRING ;

   LIBRARY LEF_CDN_CONSTRAINTLENGTH STRING ;

   LIBRARY LEF_CDN_CUTMASKTRACK STRING ;

   LIBRARY LEF_CDN_FINFET STRING ;

   LIBRARY LEF_CDN_IMPLANTGROUP STRING ;

   LIBRARY LEF_CDN_LAYERMASKSHIFT STRING ;

   LIBRARY LEF_CDN_MAXFLOATINGAREA STRING ;

   LIBRARY LEF_CDN_MAXVIASTACK STRING ;

   LIBRARY LEF_CDN_METALWIDTHTRACK STRING ;

   LIBRARY LEF_CDN_METALWIDTHVIAMAP STRING ;

   LIBRARY LEF_CDN_OALAYERMAP STRING ;

   LIBRARY LEF_CDN_PGVIATRACK STRING ;

   LIBRARY LEF_CDN_STACKVIALAYERRULE STRING ;

   LIBRARY LEF_CDN_STACKVIARULE STRING ;

   LIBRARY LEF_CDN_TAPDISTANCE STRING ;

   LIBRARY LEF_CDN_TAPDISTANCERULE STRING ;

   LIBRARY LEF_CDN_TRIMMETALTRACK STRING ;

   LIBRARY LEF_CDN_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 LEF_CDN_ANTENNAMAXCUMAREA STRING
   "ANTENNAMAXCUMAREA value [RANGE bottomLayer topLayer]
      [CUTLAYERONLY]
      ;" ;
END PROPERTYDEFINITIONS

Where:

Antenna Maximum Cumulative Area Rule Example

• The following rule means that the antenna is only measured on the cut layers, VIA5 - VIA7, on the given layer range.
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_ANTENNAMAXCUMAREA STRING

      ANTENNAMAXCUMAREA 100.00 RANGE M5 M8 CUTLAYERONLY ; " ;

  END PROPERTYDEFINITIONS

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 LEF_CDN_ANTENNAMAXGATEAREA STRING
   "ANTENNAMAXGATEAREA {OXIDE1 | OXIDE2 | OXIDE3 | OXIDE4 | OXIDE5 
      | ... | OXIDE32} max_area 
      ; " ;
END PROPERTYDEFINITIONS

Where:

Antenna Model Group Rule

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

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

Where:

Antenna Model Group Rule Examples

• The following rule means that if two pins are electrically connected with pin1 having model OXIDE1 and pin2 having model OXIDE2, OXIDE3 by combining OXIDE1 and OXIDE2 would be checked while the individual OXIDE1 and OXIDE2models would be ignored.
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_ANTENNAMODELGROUP STRING “

       ANTENNAMODELGROUP OXIDE3 MODEL OXIDE1 OXIDE2 ; ” ;

  END PROPERTYDEFINITIONS

• The following rule indicates that if two pins are electrically connected with pin1 having model OXIDE1 and pin2 having model OXIDE2, OXIDE1 and OXIDE2 would be checked separately while OXIDE4 would be ignored because not all of the models in the model group are connected.
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_ANTENNAMODELGROUP STRING “

       ANTENNAMODELGROUP OXIDE4 MODEL OXIDE1 OXIDE2 OXIDE3 ; ” ;

  END PROPERTYDEFINITIONS

• The following rule indicates that if three pins are electrically connected with pin1 having model OXIDE1, pin2 having model OXIDE2 and pin3 having model OXIDE3, OXIDE4 by combining OXIDE1 and OXIDE2 is checked along with OXIDE3, which does not belong to any model group. The individual OXIDE1 and OXIDE2models are ignored.
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_ANTENNAMODELGROUP STRING “

       ANTENNAMODELGROUP OXIDE4 MODEL OXIDE1 OXIDE2 ; ” ;

  END PROPERTYDEFINITIONS

• The following rule indicates that if two pins are electrically connected with pin1 having model OXIDE1 and OXIDE3 and pin2 having model OXIDE2 and OXIDE4, OXIDE5 by combining OXIDE1 and OXIDE2 and OXIDE6 by combining OXIDE3 and OXIDE4 would only be checked separately.
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_ANTENNAMODELGROUP STRING “

       ANTENNAMODELGROUP OXIDE5 MODEL OXIDE1 OXIDE2 ; 

       ANTENNAMODELGROUP OXIDE6 MODEL OXIDE3 OXIDE4 ; ” ;

  END PROPERTYDEFINITIONS

• The following illustration is an example of the rule below.
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_ANTENNAMODELGROUP STRING “

       ANTENNAMODELGROUP OXIDE3 MODEL OXIDE1 OXIDE2 ; ” ; 

  END PROPERTYDEFINITIONS

  
  Figure 1-1 Illustration of the Antenna Model Group Rule
  

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 LEF_CDN_CONSTRAINTLENGTH STRING
"CONSTRAINTLENGTH length {MAX|MIN} [HORIZONTAL|VERTICAL] 
      [EXCEPTABUTTED] [WIDTH minWidth]
      CONSTRAINTAREATYPE {typeName | VERTICALCELLEDGESTACK
            | HORIZONTALCELLEDGESTACK}
      ;" ;

END PROPERTYDEFINITIONS

Where:

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 LEF_CDN_CELLEDGESPACINGTABLE STRING 
    "CELLEDGESPACINGTABLE [NODEFAULT]
      {EDGETYPE {edgeType1 | DEFAULT} 
      {edgeType2 | DEFAULT} [EXCEPTABUTTED] 
            [EXCEPTNONFILLERINBETWEEN]
            [OPTIONAL | SOFT | EXACT] spacing} ...
      ;...” ;
END PROPERTYDEFINITIONS

Where:

Cell Edge Spacing Table Rule Examples

• The following rule indicates that:
  • 0.1 µm is the spacing between a macro edge with type GROUP1 and a macro edge with type GROUP2. Abutting the two macros is also allowed.
  • 0.2 µm is the optional spacing between two macro edges with type GROUP1; a certain placement option controls whether or not it is honored.
  • 0.3 µm is the spacing between a macro edge with type GROUP2 and a macro edge without a type.
  • 0.4 µm is the soft spacing between two macro edges with type GROUP2, which would be ignored if placement quality is impacted too much.
  • 0.5 µm spacing is not allowed between a macro edge with type GROUP1 and a macro edge without a type.
  • The rest of the combination of edges, DEFAULT to DEFAULT, do not have any spacing constraint, or 0.0 µm.
  
  

  PROPERTYDEFINITIONS
    LIBRARY LEF_CDN_CELLEDGESPACINGTABLE STRING
      "CELLEDGESPACINGTABLE 
          EDGETYPE GROUP1 GROUP2 EXCEPTABUTTED 0.1
          EDGETYPE GROUP1 GROUP1 OPTIONAL 0.2
          EDGETYPE GROUP2 DEFAULT 0.3 
          EDGETYPE GROUP2 GROUP2 SOFT 0.4; ";
          EDGETYPE GROUP1 DEFAULT EXACT 0.5; ";
  END PROPERTYDEFINITIONS

• The following rule illustrates the cell edge spacing rule for the given macro definition:
  

  PROPERTYDEFINITIONS
    LIBRARY LEF_CDN_CELLEDGESPACINGTABLE STRING
      "CELLEDGESPACINGTABLE
          EDGETYPE GROUP1 GROUP1 0.001 ; “ ;
  END PROPERTYDEFINITIONS

  
  Figure 1-4 Illustration of Cell Edge Spacing Rule
  
• The following rule illustrates a cell edge spacing rule with EXCEPTNONFILLERINBETWEEN:
  

  PROPERTYDEFINITIONS
    LIBRARY LEF_CDN_CELLEDGESPACINGTABLE STRING
      "CELLEDGESPACINGTABLE EDGETYPE E1 E1
          EXCEPTNONFILLERINBETWEEN 1.5; " ;
  END PROPERTYDEFINITIONS

  
  Figure 1-5 Illustration of Cell Edge Spacing Rule with EXCEPTNONFILLERINBETWEEN
  

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 LEF_CDN_CELLVARIANTS STRING
"CELLVARIANTS variantTotalNum 
     [STARTVARIANT startVariant [XFLIPSTARTVARIANT startVariant]]
     YFLIPMAP {flippedVariantNum siteVariantNum}...
     [XFLIPMAP {cellVariantNum siteVariantNum}... ]
     ;" ;
END PROPERTYDEFINITIONS

Where:

Cell Variants Rule Examples

• The following example illustrates the cell variant rule:
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_CELLVARIANTS STRING "

  CELLVARIANTS 3 YFLIPMAP 1 1 2 3 3 2 ; " ;

  END PROPERTYDEFINITIONS

  ...

  MACRO A

  ...

  END A 

  MACRO A2

  PROPERTY LEF_CDN_EEQ " EEQ A VARIANT 2 ; " ;

  ...

  END A2

  MACRO A3

  PROPERTY LEF_CDN_EEQ " EEQ A VARIANT 3 ; " ;

  ...

  END A3

  
  Figure 1-6 Illustration of the Cell Variants Rule
  
• The following example illustrates a cell variant rule with XFLIPMAP:
  

  LIBRARY LEF_CDN_CELLVARIANTS STRING "

       CELLVARIANTS 4 STARTVARIANT 1 XFLIPSTARTVARIANT 2 

       YFLIPMAP { 1 2 2 1 3 2 4 1 } XFLIPMAP { 1 0 2 0 3 1 4 2 } ; “ ;

  END PROPERTYDEFINITIONS

  
  Figure 1-7 Illustration of the Cell Variants Rule with XFLIPMAP
  

• The following example illustrates a cell variant rule with XFLIPMAP:
  

  LIBRARY LEF_CDN_CELLVARIANTS STRING "

       CELLVARIANTS 4 STARTVARIANT 1 XFLIPSTARTVARIANT 2 

       YFLIPMAP { 1 2 2 1 3 2 4 1 } XFLIPMAP { 1 0 2 0 3 1 4 2 } ; “ ;

  END PROPERTYDEFINITIONS

  
  Figure 1-8 Illustration of the Cell Variants Rule with XFLIPMAP
  

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 LEF_CDN_CUTMASKTRACK STRING

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

Where:

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 LEF_CDN_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 LEF_CDN_FINFET STRING
"FINFET 
     PITCH pitch [OFFSET offset] {HORIZONTAL|VERTICAL} 
         [NOCORECELL]
     ;" ;
END PROPERTYDEFINITIONS

Where:

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

FinFET Rule Example

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

PROPERTYDEFINITIONS

LIBRARY LEF_CDN_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 LEF_CDN_IMPLANTGROUP STRING
   "IMPLANTGROUP groupName 
       LAYER {layerName}... BASEDLAYER basedLayerName
      ;" ;
END PROPERTYDEFINITIONS

Where:

IMPLANTGROUP groupName 
     LAYER {layerName}... BASEDLAYER basedLayerName

Implant Group Rule Example

PROPERTYDEFINITIONS
LIBRARY LEF_CDN_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 LEF_CDN_LAYERMASKSHIFT STRING
"LAYERMASKSHIFT layer1 [layer2 ...]
     [MACROCLASS { RING | BLOCK | PAD | CORE | ENDCAP }...]
     ;" ;

END PROPERTYDEFINITIONS

Where:

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

Layer Mask Shift Rule Examples

• The following example indicates that mask-shifting is allowed on LEF layer M1 and VIA1 but not on other layers:
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_LAYERMASKSHIFT STRING "

     LAYERMASKSHIFT M1 VIA1 ; " ;

  END PROPERTYDEFINITIONS

• The following example indicates that mask-shifting is allowed on the LEF layer M1 and VIA1 on MACRO with class CORE or ENDCAP but not on other layers and macros with other classes. In addition, FIXEDMASK on MACRO A means that mask-shifting on MACRO A is not allowed on all layers:
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_LAYERMASKSHIFT STRING "

     LAYERMASKSHIFT M1 VIA1 MACROCLASS CORE ENDCAP ; “ ;

  END PROPERTYDEFINITIONS

  MACRO A

     CLASS CORE ;

     FIXEDMASK ;

  ...

  END A

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 LEF_CDN_MAXFLOATINGAREA STRING
 "MAXFLOATINGAREA maxArea 
  {SINGLELAYER | CONNECTED | ALLCONNECTED} minRoutingLayer maxRoutingLayer 
   [[LAYERS minRoutingLayer maxRoutingLayer]
     SPACING minSpacing [PARSPACING minParSpacing minParallelLength ...]] ... ;" ;
END PROPERTYDEFINITIONS

Where:

Maximum Floating Area Rule Examples

• Example 1
  Assume the following rule exists:

  PROPERTYDEFINITIONS
    LIBRARY LEF_CDN_MAXFLOATINGAREA STRING 
      “MAXFLOATINGAREA 1000 SINGLELAYER m1 m6 SPACING 1.0 ;” ;
  END PROPERTYDEFINITIONS 

  Every shape on layers m1 to m6 with maximum floating area greater than 1000 μm² must have spacing of greater than or equal to 1.0 μm to any grounded metal.
• Example 2
  Assume the following rule exists:

  PROPERTYDEFINITIONS
    LIBRARY LEF_CDN_MAXFLOATINGAREA STRING 
      “MAXFLOATINGAREA 1000 CONNECTED m1 m6 
        LAYERS m1 m1 SPACING 1.0 PARSPACING 0.5 0.8 0.2 2.0
        LAYERS m2 m6 SPACING 0.6 PARSPACING 0.3 0.9 ;” ;
  END PROPERTYDEFINITIONS 

  For layer m1, any floating metal must be either greater than or equal to 1.0 μm distance from grounded metal, or:
  • If it is greater than or equal to 0.5 μm distance away, there must be at least 0.8 μm of parallel length at the minimum spacing.
  • If it is greater than or equal to 0.2 μm distance away, there must be at least 2.0 μm of parallel length at the minimum spacing.
  
  Spacing that is less than 0.2 μm is not allowed.
  Any floating m2 through m6 shapes with area that is greater than 1000 μm², must either be greater than or equal to 0.6 μm distance from grounded metal, or they must be greater than or equal to 0.3 μm distance away with greater than or equal to 0.9 μm of parallel length.
  See Figure 1-9 for different layout examples using this rule.
  Figure 1-10 Maximum Floating Area Rule
  

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 LEF_CDN_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:

Maximum Via Stack Rule Examples

• If the following rule exists:
  

  PROPERTYDEFINITIONS
    LIBRARY LEF_CDN_MAXVIASTACK STRING 
      “MAXVIASTACK 3 RANGE m1 m6  ;” ;
  END PROPERTYDEFINITIONS 

  Only three single-cut vias can be stacked between layers m1 and m6. See Figure 1-10 for different layout examples using this rule.
  Figure 1-11 Max Via Stack Rule Examples
  
• The following rule applies if metal shapes containing the stacked vias have an area less than the individual area of 0.1 on any layer:
  

  PROPERTYDEFINITIONS
    LIBRARY LEF_CDN_MAXVIASTACK STRING
      “MAXVIASTACK 2 EXCEPTAREA 0.1 0.15
          RANGE M2 M6 ; ” ;
  END PROPERTYDEFINITIONS

  
  Figure 1-12 Illustration of Max Via Stack Rule with EXCEPTAREA
  
• The following property rule illustrates WITHIN LOWCUTSIZE with V1 layer:
  

  PROERPTY LEF_CDN_CUTCLASS 
      “CUTCLASS ...  WIDTH 0.06 ... ;
       CUTCLASS ...  WIDTH 0.12 ... ; ” ;

  
  Figure 1-13 Illustration of Max Via Stack Rule with WITHIN LOWCUTSIZE
  
  Figure 1-14 Illustration of Max Via Stack Rule with WITHIN
  
• The following property rule illustrates the max via stack rule with NOVIALIST:
  

  PROPERTYDEFINITIONS
        LIBRARY LEF_CDN_MAXVIASTACK STRING “
                  MAXVIASTACK 3 NOVIALIST V1B V2C ; “ ;
  END PROPERTYDEFINITIONS

  
  Figure 1-15 Illustration of Max Via Stack Rule with NOVIALIST
  
• The following property rule illustrates multiple max via stack rules:
  

  PROPERTYDEFINITIONS
       LIBRARY LEF_CDN_MAXVIASTACK STRING “
            MAXVIASTACK 2 RANGE M1 M5 ;
            MAXVIASTACK 3 RANGE M3 M7 ; “ ;
  END PROPERTYDEFINITIONS

  
  Figure 1-16 Illustration of Multiple Max Via Stack Rules
  
• The following example illustrates the max via stack rule with CENTERCUTWITHIN:
  

  PROPERTYDEFINITIONS
  LIBRARY LEF_CDN_MAXVIASTACK STRING “
        MAXVIASTACK 3 
              CENTERCUTWITHIN V3 0.000 0.020
              RANGE M1 M5 ; ” ;
  END PROPERTYDEFINITIONS

  
  Figure 1-17 Illustration of Max Via Stack Rule with CENTERCUTWITHIN
  
• The following property rule illustrates a max via stack rule with EXCEPTCUTCLASSLIST:
  

  PROPERTYDEFINITIONS
       LIBRARY LEF_CDN_MAXVIASTACK STRING “
            MAXVIASTACK 2
            EXCEPTCUTCLASSLIST V2 V2C; ” ;
  END PROPERTYDEFINITIONS

  
  Figure 1-18 Illustration of Max Via Stack Rule with EXCEPTCUTCLASSLIST
  

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 LEF_CDN_METALWIDTHTRACK STRING
“METALWIDTHTRACK routingLayer COREOFFSET offset
    {WIDTH width PITCH pitch [REPEAT repeat]}...
    ;” ;
END PROPERTYDEFINITIONS

Where:

METALWIDTHTRACK M1 ...

METALWIDTHTRACK M2 ...

METALWIDTHTRACK M1 ...

METALWIDTHTRACK M1 ...

Metal Width Track Rule Example

• The following example is an illustration of the metal track width rule:
  

  LAYER M1

   TYPE ROUTING ;

   DIRECTION HORIZONTAL ;

   ...

  END M1

  ...

  LIBRARY LEF_CDN_METALWIDTHTRACK STRING

            “METALWIDTHTRACK M1 COREOFFSET 0.15

                  WIDTH 0.2 PITCH 0.4

                  WIDTH 0.1 PITCH 0.2 REPEAT 4

                  WIDTH 0.1 PITCH 0.4 ; “ ;

  END PROPERTYDEFINITIONS

  
  Figure 1-19 Illustration of Metal Track Width Rule
  

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 LEF_CDN_METALWIDTHVIAMAP STRING
   "METALWIDTHVIAMAP
       [USEVIACUTCLASS]
       {VIA viaLayer 
          {belowLayerWidth aboveLayerWidth 
          |belowLayerLowWidth belowLayerHighWidth 
             aboveLayerLowWidth aboveLayerHighWidth} 
          viaName [PGVIA]}...
       ;..." ;

END PROPERTYDEFINITIONS

Where:

LIBRARY LEF_CDN_METALWIDTHVIAMAP STRING "
METALWIDTHVIAMAP USEVIACUTCLASS
VIA V1 0.05 0.08 V1_CUTCLASSA ; " ;

END PROPERTYDEFINITIONS

VIA viaLayer belowLayerLowWidth belowLayerHighWidth 
           aboveLayerLowWidth aboveLayerHighWidth viaName...

Metal Width Via Map Rule Examples

• The following example indicates that V1_SMALL should be used on cut layer V1 for below metal width of 0.05 and above metal width of 0.08 wires while V1_LARGE should be used for below metal width of 0.07 and above metal width of 0.08 wires:
  

  PROPERTYDEFINITIONS
  LIBRARY LEF_CDN_METALWIDTHVIAMAP STRING “
         METALWIDTHVIAMAP VIA V1 0.05 0.08 V1_SMALL 
           VIA V1 0.07 0.08 V1_LARGE; ” ;
  END PROPERTYDEFINITIONS

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 LEF_CDN_OALAYERMAP STRING
   “OALAYERMAP oaLayer
{ [PURPOSE oaPurpose] BLOCKAGE layer
      | LAYER layer [MASK maskNum] }
      ;...” ;
END PROPERTYDEFINITIONS

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

OpenAccess Layer Map Rule Examples

• The following example indicates that the LEF layer M1 is mapped to OpenAccess layer Metal1:
  

  PROPERTYDEFINITIONS
  LIBRARY LEF_CDN_OALAYERMAP STRING “
       OALAYERMAP Metal1 LAYER M1 ; “ ;
  END PROPERTYDEFINITIONS

• The following example indicates that the LEF MASK 1 shapes on M1 would go to OpenAccess layer Metal1A while MASK 2 shapes on M1 would go to OpenAccess layer Metal1B:
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_OALAYERMAP STRING “
       OALAYERMAP Metal1A LAYER M1 MASK 1 ; 
       OALAYERMAP Metal1B LAYER M1 MASK 2 ; “ ;
  END PROPERTYDEFINITIONS

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 LEF_CDN_PGVIATRACK STRING
   “PGVIATRACK cutLayer COREOFFSET offset PITCH pitch; “ ;
END PROPERTYDEFINITIONS

Where:

PG Via Track Rule Example

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

PROPERTYDEFINITIONS
LIBRARY LEF_CDN_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 LEF_CDN_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:

STACKVIALAYERRULE ruleName
   LAYER cutLayerName [CUTCLASS className]
      ROWCOL numCutRows numCutCols

Stack Via Layer Rule Examples

• The following example is an illustration of the stack via layer rule:
  

  PROPERTY LEF_CDN_STACKVIALAYERRULE “

     STACKVIALAYERRULE SVLR1 LAYER VIA1 CUTCLASS VA1 

        ROWCOL 2 3 XPITCH 2 YPITCH 3  ;

     STACKVIALAYERRULE SVLR2 LAYER VIA2 CUTCLASS VA2 

        ROWCOL 2 2 XPITCH 3 YPITCH 3 

        BELOWMINLENGTH 0.3 ; “ ; 

  PROPERTY LEF_CDN_STACKVIARULE “

     STACKVIARULE SVR1 SVLR1 SVLR2 ; “ ;

  
  Figure 1-21 Illustration of Stack Via Layer Rules
  
  Figure 1-22 Illustration of MAXCELLEXTENSION extensionPitch
  
  Figure 1-23 Illustration of OFFGRIDCUT
  
  Figure 1-24 Illustration of MAXXLINEEND with Negative Values for maxLeftExtension and maxRightExtension
  

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 LEF_CDN_STACKVIARULE STRING
“STACKVIARULE ruleName {stackLayerRuleName}...[EMFACTOR emFactor]
     ; “ ;
END PROPERTYDEFINITIONS

Where:

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 LEF_CDN_TAPDISTANCE STRING
“TAPDISTANCE {distance | TAPDISTANCERULE ruleName
     |{HALFROW rowNum [LEFT|RIGHT] 
         {distance | TAPDISTANCERULE ruleName}}...}
     TAPTYPE typeName
     ; “ ;
END PROPERTYDEFINITIONS

Where:

Tap Distance Rule Example

• The following example is an illustration of the tap distance rule:
  

  PROPERTYDEFINITIONS

  LIBRARY LEF_CDN_TAPDISTANCE STRING “
       TAPDISTANCE HALFROW 1 2.4 
            HALFROW 2 2.0 TAPTYPE TAP1
       TAPDISTANCE HALFROW 1 1.2 HALFROW 2 1.2
            HALFROW 3 LEFT 0 HALFROW 3 RIGHT 0.8
            HALFROW 4 LEFT 0 HALFROW 4 RIGHT 0.8
            TAPTYPE TAP2 ; “ ;
  END PROPERTYDEFINITIONS

  
  Figure 1-25 Illustration of Tap Distance Rule
  

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 LEF_CDN_TAPDISTANCERULE STRING
“TAPDISTANCERULE ruleName DEFAULT distance
     [LAYER layerName layerDistance]...

     ; ”;
END PROPERTYDEFINITIONS

Where:

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 LEF_CDN_TRIMMETALTRACK STRING
"TRIMMETALTRACK trimLayer [GROUP groupName]
     [ONTRACK [HALFINFILLER | HALFNONMERGED]
         [INCLUDELINEEND [TRIMCENTER]]]
     [MASK maskNum
     |METALTRACKOFFSET trackNumber METALTRACKPITCH trackPitch] 
     COREOFFSET offset PITCH pitch
     ;" ;

END PROPERTYDEFINITIONS

Where:

Trim Metal Track Rule Examples

• Consider the following example:
  

  LAYER TM1
       TYPE MASTERSLICE ;
       MASK 2 ;
       PROPERTY LEF_CDN_TYPE “TYPE TRIMMETAL ; ” ;
       PROPERTY LEF_CDN_TYPE “TYPE TRIMMEDMETAL M1 ; ” ;

       ...
  END TM1

  ...

  LAYER M1
       TYPE ROUTING ;
       DIRECTION VERTICAL ;
       ...
  END M1

  ...

  PROPERTYDEFINITIONS
  LIBRARY LEF_CDN_TRIMMETALTRACK STRING “
             TRIMMETALTRACK TM1 MASK 1 COREOFFSET 0.01 PITCH 0.2 ;
             TRIMMETALTRACK TM1 MASK 1 COREOFFSET 0.12 PITCH 0.2 ;
             TRIMMETALTRACK TM1 MASK 2 COREOFFSET 0.08 PITCH 0.2 ;
             TRIMMETALTRACK TM1 MASK 2 COREOFFSET 0.19 PITCH 0.2 ;
  END PROPERTYDEFINITIONS

  The above example means that the trim metal layer of TM1 has two sets of horizontal tracks on MASK 1 with starting y locations of 0.01 and 0.12 with respect to the origin of the core with repeatable pitch of 0.2, and it has another two sets of horizontal tracks on MASK 2 with starting y locations of 0.08 and 0.19 with respect to the origin of the core with repeatable pitch of 0.2.
• The following example is an illustration of the trim metal track rule with METALTRACKOFFSET and METALTRACKPITCH:
  

  TRIMMETALTRACK TM1 METALTRACKOFFSET 1 METALTRACKPITCH 3
      COREOFFSET O1 PITCH P ;

  TRIMMETALTRACK TM1 METALTRACKOFFSET 2 METALTRACKPITCH 3
      COREOFFSET O2 PITCH P ;

  TRIMMETALTRACK TM1 METALTRACKOFFSET 3 METALTRACKPITCH 3
      COREOFFSET O3 PITCH P ;

  
  Figure 1-26 Illustration of Trim Metal Track Rule
  

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 LEF_CDN_VOLTAGEMODE STRING
“VOLTAGEMODE ABSOLUTE
     ; “ ;
END PROPERTYDEFINITIONS

Where:

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] ...
[OBSSPACING { FULLDRC | MIN | spacing } [LAYER layer] ... ; ...
[DENSITY statement] ...
[PROPERTY propName propVal ;] ...
[PROPERTY LEF_CDN_ACCESSAREA
   "ACCESSAREA {LAYER layerName RECT pt pt [CUTCLASS className]
   [EXCEPTEXTRACUT]}...
   ; " ;]
[PROPERTY LEF_CDN_ALIGNPGVIATOTRACK
   "ALIGNPGVIATOTRACK
   ; " ;]
[PROPERTY LEF_CDN_ALLPINSCONNECTED
   "ALLPINSCONNECTED
   ; " ;]
[PROPERTY LEF_CDN_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 LEF_CDN_CONSTRAINTAREATYPE
   "CONSTRAINTAREATYPE typeName {RECT pt pt}...
    ;..." ;]
[PROPERTY LEF_CDN_EDGETYPE
   "EDGETYPE {RIGHT | LEFT | TOP | BOTTOM}
    edgeType | BOTHSOURCE | SOURCEDRAIN | DRAINSOURCE | BOTHDRAIN 
    | BOTHFLOATING
    [CELLROW cellRow  | HALFROW halfRow | RANGE xLow xHigh]
    ;..." ;]
[PROPERTY LEF_CDN_EEQ
   "EEQ macroName [VARIANT num]
    ;... " ;]
[PROPERTY LEF_CDN_FOREIGN
   "FOREIGN foreignCellName [pt [orient]] 
         [COMPORIENT foreignOrientName {compOrient}...]...
    ;... " ;]
[PROPERTY LEF_CDN_LAYERMASKSHIFT
   "LAYERMASKSHIFT layer1 [layer2 ...] 
    ;... " ;]
[PROPERTY LEF_CDN_OBSPARTIAL
  "OBSPARTIAL {LAYER layerName 
    WIDTH width SPACING spacing RECT pt pt}...
  ; " ;]
[PROPERTY LEF_CDN_PLACEWITHIN
  "PLACEWITHIN within PRL prl {WITH|WITHOUT} LAYER {layerName}...
  ; " ;]
[PROPERTY LEF_CDN_REQ
   "REQ macroName 
    ; " ;]
[PROPERTY LEF_CDN_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:

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] ...

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:

• • Corresponding pins must have corresponding functionality.
  • Pins must be defined in the same order.
  • For each group of corresponding pins (one from each macro), pin function and electrical characteristics must be the same.
  • The EEQ macroName specified must refer to a previously defined macro. If the EEQ macroName referenced is already electrically equivalent to other model macros, all referenced macros are considered electrically equivalent.

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 “Layer Geometries - PORTOBS Properties” for syntax information.

OBSSPACING statement

Specifies the default meaning for OBS shapes on a given layer for DRC checking purposes. The default meaning for each layer can be overridden by specific attributes on individual OBS shapes (see ABSTRACT, REAL, SPACING and DESIGNRULEWIDTH keyword in the OBS syntax).

The OBSSPACING syntax is defined as follows:

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

If there are multiple OBSSPACING statements, later statements overwrite earlier statements (see the example).

If OBSSPACING is not given, the default meaning of OBS shapes depends on whether the macro is a standard-cell or not. Standard cells have all OBS shapes treated as "real" geometry that needs full DRC checking (equivalent to OBSSPACING FULLDRC), while other cells, such as blocks and IO pads, treat OBS shapes as abstract shapes that need min-spacing (equivalent to OBSSPACING MIN).

A standard cell is any macro that has a SITE where the SITE definition has CLASS CORE so the placer knows how to place it in the core rows. A macro, such as a block, pad, or corner cell, without any SITE or with a SITE that has CLASS PAD is not a standard-cell macro.

Example 1-5 Macro OBS Spacing

The following statements mean that all of the OBS on M7 and M8 are treated as real geometries that get full DRC checks, while OBS on the other layers are abstract shapes that require min-spacing to other objects.

OBSSPACING MIN ;   #Default for all layers

OBSSPACING FULLDRC LAYER M7 LAYER M8 ; " ;

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:

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]

Example 1-6 Macro Site

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

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:

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.

• Properties belong to the MACRO/PIN object and have a type of STRING.
• The property names used for these rules all start with LEF_CDN_.

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 LEF_CDN_ACCESSAREA STRING ;

     MACRO LEF_CDN_ALIGNPGVIATOTRACK STRING ;

     MACRO LEF_CDN_ALLPINSCONNECTED STRING ;

     MACRO LEF_CDN_CLASS STRING ;

     MACRO LEF_CDN_CONSTRAINTAREATYPE STRING ;

     MACRO LEF_CDN_EDGETYPE STRING ;

     MACRO LEF_CDN_EEQ STRING ;

     MACRO LEF_CDN_FOREIGN STRING ;

     MACRO LEF_CDN_LAYERMASKSHIFT STRING ;

     MACRO LEF_CDN_OBSPARTIAL 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 LEF_CDN_ACCESSAREA
   "ACCESSAREA {LAYER layerName RECT pt pt [CUTCLASS className]
   [EXCEPTEXTRACUT]}...
   ; " ;

Where:

Area Access Rule Examples

• The following example means that the cuts of VIA1 of VA must be inside 1.0 1.0 2.0 2.0 and the cuts of VIA1 of the other cut class must be inside 1.5 1.5 2.2 2.2 when connecting to a M1 (below metal layer) pin shape that overlaps with the given area.
  

  PROPERTY LEF_CDN_ACCESSAREA "
       ACCESSAREA LAYER VIA1 RECT 1.0 1.0 2.0 2.0 CUTCLASS VA 
            LAYER VIA1 RECT 1.5 1.5 2.2 2.2 ; " ;

• The following example means that the cuts of VIA1 of VA must be inside 1.0 1.0 2.0 2.0 when connect to a M1 (below metal layer) pin shape that overlaps with the given area and the cuts of VIA1 of the other cut class does not have any restriction.
  

  PROPERTY LEF_CDN_ACCESSAREA "
       ACCESSAREA LAYER VIA1 RECT 1.0 1.0 2.0 2.0 CUTCLASS VA ; " ;

• The diagram below illustrates the following access area rule:
  

  PROPERTY LEF_CDN_ACCESSAREA “
       ACCESSAREA LAYER VIA1 RECT 1.0 1.0 3.5 1.8 
            EXCEPTEXTRACUT 
            LAYER VIA1 RECT 6.0 0.5 7.0 1.0 
            LAYER VIA1 RECT 6.0 1.8 7.0 2.5 ; “ ;

  
  Figure 1-30 Illustration of the Access Area Rule
  

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 LEF_CDN_ALIGNPGVIATOTRACK 
"ALIGNPGVIATOTRACK
   ;..." ;

Where:

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 LEF_CDN_ALLPINSCONNECTED
   "ALLPINSCONNECTED
   ; " ;

Where:

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 LEF_CDN_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.

Class Rule Examples

• The following example indicates that macro A is a cover macro for metal filling purpose:
  

  MACRO A

      PROPERTY LEF_CDN_CLASS “CLASS COVER FILL ; ” ;

  ...

  END A

• The following example shows four different set of configurations for class rule:
  Figure 1-31 Illustration of Class Rule
  
• The following example shows the use of RIGHTEDGE (RE), TOPEDGE (TE), LEFTOPEDGE (LTE) and LEFTTOPCORNER (LTC) endcap cells:
  • RIGHTEDGE in N and FS orientation is used in start of rows
  • RIGHTEDGE in FN and S orientation is used in end of rows
  • TOPEDGE in N orientation is used in bottom row of the core or top row right above a block macro (the first row should have N orientation; otherwise, the bottom FS row would be wasted)
  • TOPEDGE in FS orientation is used in top row of the core or bottom row right below a block macro
  • LEFTTOPEDGE is used at the 4 outer corners in N (left-bottom corner), FN (right-bottom), S (right-top) and FS (left-top) orientation
  • LEFTTOPCORNER is used at the 4 inner corners similarly. Hence, all the cells must have SYMMETRY X Y.
    Figure 1-32 Illustration of Class Rule
    
    Figure 1-33 Illustration of Class Rule
    
    Figure 1-34 Illustration of LEFTEDGETOPBORDER, LEFTEDGEBOTTOMBORDER, RIGHTEDGETOPBORDER and RIGHTEDGEBOTTOMBORDER
    
    Figure 1-35 Illustration of LEFTTOPEDGENEIGHBOR,RIGHTTOPEDGENEIGHBOR, LEFTBOTTOMEDGENEIGHBOR, RIGHTBOTTOMEDGENEIGHBOR, LEFTTOPCORNERNEIGHBOR, RIGHTTOPCORNERNEIGHBOR, LEFTBOTTOMCORNERNEIGHBOR and RIGHTBOTTOMCORNERNEIGHBOR
    
    Figure 1-36 Illustration of LEFTCORNERTOPBORDER, RIGHTCORNERTOPBORDER, LEFTCORNERBOTTOMBORDER, RIGHTCORNERBOTTOMBORDER, TOPCORNEREDGENEIGHBOR, and BOTTOMCORNEREDGENEIGHBOR
    
    Figure 1-37 Illustration of TSV* End Cap Cells
    

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 LEF_CDN_CONSTRAINTAREATYPE
   "“CONSTRAINTAREATYPE typeName {RECT pt pt}...
    ;...” ;

Where:

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 LEF_CDN_EDGETYPE 
"EDGETYPE {RIGHT | LEFT | TOP | BOTTOM}
    edgeType | BOTHSOURCE | SOURCEDRAIN | DRAINSOURCE | BOTHDRAIN 
    | BOTHFLOATING 
    [CELLROW cellRow  | HALFROW halfRow | RANGE xLow xHigh]
    ;..." ;

Where:

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

• The following statement indicates that edge type GROUP1 contains the right edge of MACRO1 and GROUP2 contains the left edge of MACRO1 and right edge of MACRO2:
  

  MACRO MACRO1

  …

  PROPERTY LEF_CDN_EDGETYPE "

  EDGETYPE RIGHT GROUP1 ;

  EDGETYPE LEFT GROUP2 ; " ;

  END MACRO1

  MACRO MACRO2

  …

  PROPERTY LEF_CDN_EDGETYPE "

  EDGETYPE RIGHT GROUP2 ; " ;

  END MACRO2

• The following example indicates that GROUP1 and GROUP2 are defined on the first and last (third) row, respectively, on the left edge for the triple-height cell:
  

  PROPERTY LEF_CDN_EDGETYPE "

  EDGETYPE LEFT GROUP1 CELLROW 1 ;

  EDGETYPE LEFT GROUP2 CELLROW 3 ; " ;

  
  Figure 1-38 Illustration of Macro with Cell Row
  

• The following example indicates that GROUP1 and GROUP2 are defined on the first and last (fourth) half row, respectively, on the right edge of the double-height cell:
  

  PROPERTY LEF_CDN_EDGETYPE "

  EDGETYPE RIGHT GROUP1 HALFROW 1 ;

  EDGETYPE RIGHT GROUP2 HALFROW 4 ; " ;

  
  Figure 1-39 Illustration of Macro with Half Row
  

• The following example illustrates the edge type rule with special edge type keywords:
  

  MACRO A

  ...

     PROPERTY LEF_CDN_EDGETYPE

        "EDGETYPE LEFT DRAINSOURCE ;

         EDGETYPE RIGHT SOURCEDRAIN ; " ;

  ...

  END A

  MACRO B

  ...

     PROPERTY LEF_CDN_EDGETYPE "

        EDGETYPE LEFT BOTHDRAIN ; 

        EDGETYPE RIGHT BOTHSOURCE ; " ;

  ...

  END B

  
  Figure 1-40 Illustration of Macro with special edge type keywords
  
  Figure 1-41 Illustration of Macro with Range
  

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 LEF_CDN_EEQ 
     "EEQ macroName [VARIANT num]
     ;... " ;

Where:

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

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 LEF_CDN_FOREIGN 
     "FOREIGN foreignCellName [pt [orient]] 
          [COMPORIENT foreignOrientName {compOrient}...]...
     ;... " ;

Where:

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

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 LEF_CDN_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 LEF_CDN_LAYERMASKSHIFT
"LAYERMASKSHIFT layer1 [layer2 ...]
     ;" ;

Where:

LAYERMASKSHIFT layer1 [layer2 ...]

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 LEF_CDN_OBSPARTIAL
"OBSPARTIAL {LAYER layerName 
WIDTH width SPACING spacing RECT pt pt}...
; " ;

Where:

OBS Partial Rule Example

MACRO A

...

PROPERTY LEF_CDN_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

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 LEF_CDN_PLACEWITHIN
  "PLACEWITHIN within PRL prl {WITH|WITHOUT} LAYER {layerName}...
  ; " ;

Where:

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 LEF_CDN_REQ
   "REQ macroName 
    ; " ;

Where:

REQ macroName

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 LEF_CDN_TAPCENTEROFFSET
  "TAPCENTEROFFSET
    {offset | {HALFROW rowNum [LEFT|RIGHT] offset}...}
  ; " ;

Where:

Tap Center Offset Rule Example

MACRO A

PROPERTY LEF_CDN_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:

• The easiest way to support a cover macro is to define the cover macro with a small size, for example, 1 by 1.
• If you want to define the cover macro with its actual size, create an overlap layer with the non-routing LAYER TYPE OVERLAP statement. You define this overlap layer (cover macro) with the macro obstruction (OBS) statement.

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-7 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-8 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-9 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-10 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

Macro Port or Obs Layer Geometries

     { LAYER layerName 
    [PROPERTY {propName propVal}] ...
    [EXCEPTPGNET]
    [REAL | ABSTRACT | NOROUTE]
    [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 
    [PROPERTY {propName propVal}] ...
    [MASK viaMaskNum] pt viaName ; 
| VIA
    [PROPERTY {propName propVal}] ...
    [MASK viaMaskNum] ITERATE pt viaName stepPattern ;
} ...

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

Note that several of the keywords, namely EXCEPTPGNET, SPACING and DESIGNRULEWIDTH, are intended only for OBS shapes to control how the “abstract” OBS shape is treated for DRC checking and routing purposes. OBS VIAs are used only to represent a “real via” and are never “abstract”, and PIN shapes and VIAs are always “real”. So these keywords are ignored if given for OBS VIAs, or PIN shapes or VIAs.

<topMaskNum><cutMaskNum><bottomMaskNum>

Example 1-11 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-12 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:

• M1 rect shape belongs to MASK 2
• M2 rect shape has no mask set
• VIA1_1 via has no mask set (all the metal and cut shapes have no mask)
• VIA1_2 via will have:
  • No mask set for the top metal shape (topMaskNum is 0 in the 031 value)
  • MASK 1 for the bottom metal shape (botMaskNum is 1 in the 031 value)
  • The bottommost, and then the leftmost cut of the via-instance is MASK 3. The mask for the other cuts of the via-instance are derived from the via-master by "shifting" the via-master cut masks to match. So if the via-master's bottomleft cut is MASK 1, then the via-master cuts on MASK 1 become MASK 3 for the via-instance, and similarly cuts on 2 to 1, and cuts on 3 to 2. See Figure 1-50.

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

Example 1-13 Layer Geometries - PORTOBS Properties

The following example shows how to use PORTOBS properties. The property value is applied until the next LAYER or VIA statement.

PROPERTYDEFINITIONS

    PORTOBS test1 INTEGER ;

    PORTOBS test2 STRING ;

END PROPERTYDEFINITION

... 

MACRO BUFX1

...

  PIN A

     PORT

       LAYER M1 PROPERTY test1 10 PROPERTY test2 "port property" ; 

       RECT 0.1 0.1 0.2 0.2 ;   #properties added to rect

       RECT 0.2 0.2 0.3 0.3 ;   #properties added to rect

       LAYER M1 ; 

       RECT 0.1 0.1 0.2 0.2 ; #no property added to rect

       VIA 0.1 0.1 via1_26 ; #no property added to via

       VIA PROPERTY test1 20 PROPERTY test2 "via prop"

           0.2 0.2 via1_26 ; #properties added to via 

       VIA 0.3 0.3 via1_26 ; #no property added to via

     END

  END A

     OBS

       LAYER M1 PROPERTY test1 10 PROPERTY test2 "obs property" ; 

       RECT 0.1 0.1 0.2 0.2 ; #properties added to rect

       RECT 0.2 0.2 0.3 0.3 ; #properties added to rect

       LAYER M1 ; 

       RECT 0.1 0.1 0.2 0.2 ; #no property added to rect

       VIA 0.1 0.1 via1_26 ; #no property added to via

       VIA PROPERTY test1 20 PROPERTY test2 “obs via prop”

           0.2 0.2 via1_26 ; #properties added to via 

       VIA 0.3 0.3 via1_26 ; #no property added to via

     END

END BUFX1

Example 1-14 Real and Abstract OBS Shapes

The following example shows how default REAL or ABSTRACT value is derived for routing layer OBS shapes:

MACRO A

 CLASS BLOCK ;

 OBSSPACING FULLDRC LAYER M6 ;  #M6 will default to REAL

 OBSSPACING 0.2 LAYER M5 ;  #M5 will default to ABSTRACT 

       #with SPACING 0.2

 #Other layers default to ABSTRACT because it is a block without a 

 #CORE SITE and the default spacing is MIN spacing

...

 OBS

  LAYER M6

   RECT 0.1 0.1 0.2 0.2 ;     #REAL due to OBSSPACING above

  LAYER M6 SPACING 0.1           #SPACING forces ABSTRACT

          RECT 0.3 0.3 0.4 0.4 ;   #with SPACING 0.1

  LAYER M6 ABSTRACT

   RECT 0.5 0.5 0.6 0.6 ;   #ABSTRACT, with implicit MIN space

  LAYER M5

         RECT 0.1 0.1 0.2 0.2 ;    #ABSTRACT with SPACING 0.2

       LAYER M5 SPACING 0.1

    RECT 0.3 0.3 0.4 0.4 ;    #ABSTRACT with SPACING 0.1

  LAYER M5 REAL

         RECT 0.5 0.5 0.6 0.6 ;     #REAL

  LAYER M4

   RECT 0.1 0.1 0.2 0.2 ;   #ABSTRACT with implicit MIN spacing

  LAYER M4 REAL

          RECT 0.3 0.3 0.4 0.4 ;   #REAL

  LAYER VIA5  # assume 0.2x0.2 is cut-size used in a VIA

   RECT 0.1 0.1 0.3 0.3 ;    #REAL, matches VIA cut-size

   RECT 100 100 200 200 ;    #ABSTRACT, not real cut-size

  #This has a semantic error that should give warning 

  LAYER M4 REAL SPACING 0.1            #REAL means SPACING is ignored

               RECT 0.5 0.5 0.6 0.6 ;   #REAL

  VIA 0.1 0.1 VIA5_26 ;          #A VIA is always treated as REAL

 END

END A

Macro Obstruction Statement

[OBS
{layerGeometries} ...

END]

Defines a set of obstructions (also called blockages) on the macro. You specify obstruction geometries by using the layer geometry syntax. See “Macro Port or Obs 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.

Figure 1-54

Macro Pin Statement

[PIN pinName
[TAPERRULE ruleName ;]
[DIRECTION {INPUT | OUTPUT [TRISTATE] | INOUT | FEEDTHRU} ;]
[USE { SIGNAL | ANALOG | POWER | GROUND | CLOCK } ;] 
[SUPPLYSENSITIVITY powerPinName ;]
[GROUNDSENSITIVITY groundPinName ;]
[SHAPE {ABUTMENT | RING | FEEDTHRU} ;]
[MUSTJOIN pinName ;]
{PORT  
  [CLASS {NONE | CORE | BUMP} ;] 
  {layerGeometries} ... 
 END} ... 
[PROPERTY propName propVal ;] ...
[PROPERTY LEF_CDN_ACCESSAREA
   "ACCESSAREA {LAYER layerName RECT pt pt [CUTCLASS className]
   [EXCEPTEXTRACUT]}...
   ; " ;]
[PROPERTY LEF_CDN_ANTENNADIFFAREA
   "ANTENNADIFFAREA [BACKSIDE][PROTECTOR] value [LAYER layerName]
   ; ..." ;]
[PROPERTY LEF_CDN_MUSTJOINALLPORTS
   "MUSTJOINALLPORTS
   ; " ;]
[PROPERTY LEF_CDN_VIAINMUSTJOIN
   "VIAINMUSTJOIN
   ; " ;]
[PROPERTY LEF_CDN_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:

• Netlist pins, including inout pins, output pins, and input pins
• Power and ground pins
• Mustjoin pins

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 B, “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 B, “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 B, “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 B, “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 B, “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-15 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 B, “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 B, “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 B, “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:  

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-16.

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:

• • A set of MUSTJOIN pins cannot have more than one schematic pin.
  • Nonschematic MUSTJOIN pins must be defined after all other pins.

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.

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} ...

PROPERTY propName propVal

Specifies a property on the logical PIN. It must be defined in the PROPERTYDEFINITIONS statement as a PIN objectType. 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:  

Figure 1-55

SUPPLYSENSITIVITY powerPinName

Specifies that this pin derives its supply from powerPinName, so the net attached to powerPinName has the voltage driving the pin. If this pin is an input pin connected to a tie-high connection (such as 1’b1 in Verilog), it should connect (possibly through a tie-off cell) 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-16.

Note: SUPPLYSENSITIVITY is needed only when there is more than one power pin in the macro. If there is only one USE POWER pin, then the supplysensitivity is automatically that one power pin.

Example 1-16 Supply Sensitivity

The following statement defines sensitivity value for a pin on the macro myMac: