C
Mapping LEF to the Technology File
LEF Data Map
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. Ensemble uses LEF as the library implementation language to build the technology and macrocell library for a family of designs. The File – Import - LEF and File – Export – LEF commands provide a mechanism for moving library data between the two systems. You can create an OpenAccess library from one or more LEF files.
This chapter maps the LEF file constructs and statements with the translated constructs and statements in the technology file in Virtuoso Studio design environment on OpenAccess.
The LEF file is divided into the following sections. You can specify statements in any order; however, data must be defined before it is used. The LEF statements in each of these sections are mapped to their equivalent technology file statements.
- Version of LEF
- Units
- Property Definitions
- Layers
- BEGINEXT Statement
- BUSBITCHARS Statement
- CLEARANCEMEASURE Statement
- MACRO Section
- DIVIDERCHAR Statement
- MANUFACTURINGGRID Statement
- Maximum Stacked Via
- NAMESCASESENSITIVE Statement
- SITE Section
- SPACING Section
- USEMINSPACING Statement
- VIA Statement
- VIARULE Statement
- VIARULE GENERATE
PINPROPERTIES, MIN FEATURE, CROSS TALK, DIELECTRIC, IRDROP, or BEGINEXT statements. Many of these constructs are no longer part of LEF syntax. LEF 5.4 onwards MIN FEATURE, CROSS TALK, DIELECTRIC, IRDROP statements are no longer exist. For details on each LEF statement, see LEF/DEF 5.6 Language Reference.
The organization of the technology file is different from the way the LEF file is organized. The technology file is organized into the following sections:
-
Controls (
controls) specify data that can be used throughout the technology file. -
Layer definitions (
layerDefinitions) define the layers that can be used throughout the technology file and in design sessions. -
Layer rules (
layerRules) specify layer attributes, such as layer materials, manufacturing grid resolutions, and current densities. -
Constraint groups (
constraintGroups) specify design constraints. -
Site definitions (
siteDefs) define scalar site definitions and arrays of scalar site definitions. -
Via definitions (
viaDefs) define standard and custom vias. -
Via specifications (
viaSpecs) define arrays of via definitions. -
Devices (
devices) define Cadence-predefined MOS andruleContactdevices and multipart path templates.
For more information on the technology file, see the Technology File and Display Resource File User Guide.
Version of LEF
The VERSION statement indicates the LEF version that was used to create a LEF file. File – Import – LEF ignores the VERSION statement. File – Export – LEF writes the VERSION statement as the first line of the LEF file.
VERSION number ;
Units
The UNITS statement block describes the units of measurement used in the LEF file and the precision for each measure in database units. The values show how to interpret the numbers in the LEF file. Following is the UNITS block syntax in LEF.
[UNITS
[ TIME NANOSECONDS convertFactor ; ]
[ CAPACITANCE PICOFARADS convertFactor ; ]
[ RESISTANCE OHMS convertFactor ; ]
[ POWER MILLIWATTS convertFactor ; ]
[ CURRENT MILLIAMPS convertFactor ; ]
[ VOLTAGE VOLTS convertFactor ; ]
[ DATABASE MICRONS convertFactor ; ]
[ FREQUENCY MEGAHERTZ convertFactor ; ]
END UNITS ]
The LEF statements in the UNITS section of LEF are mapped to the techParams subsection of the controls section in the technology file.
The syntax of the techParams subsection in the technology file is as follows:
controls(
techParams(
;(parameter value)
)
)
| LEF UNIT Statements | Technology File DFII on OpenAccess |
|---|---|
Examples
Property Definitions
The PROPERTYDEFINITIONS section of the LEF file lists the properties you can provide to libraries, pins, macros, and vias. Although the PROPERTYDEFINITION statements are not stored in OpenAccess, they are used to validate the PROPERTY attributes on objects when the LEF file is being parsed. Every property used in the LEF file must first be declared in this section of the LEF file. If a property that is not declared in the PROPERTYDEFINITIONS section is encountered, an error message is generated and the property is skipped.
Examples
If the property definitions were not present for lip, lrp, and lsp in the LEF file, then these would have been ignored and the generated ASCII Technology File would not have these property names.
Layers
There are four types of layers in a LEF file: routing layer, cut layer, masterslice, and overlap layer. The layer statements in a LEF file define layer names and associate place and route design rules with each routing layer.
The OpenAccess database defines layers in the technology file. For details on defining layers in the technology file see the Technology File and Display Resource File User Guide.
The following topics explain the syntax and the statements or constructs in each LEF layer and maps these statements to their technology file equivalents.
Routing Layer
Following is the syntax of the routing layer in LEF 5.6.
LAYERlayerNameTYPE ROUTING ; DIRECTION {HORIZONTAL | VERTICAL | DIAG45 | DIAG135} ; PITCH {distance|xDistanceyDistance} ; [DIAGPITCH {distance|diag45Distancediag135Distance} ;] WIDTHdefaultWidth; [OFFSET {distance|xDistanceyDistance} ;] [DIAGWIDTHdiagWidth;] [DIAGSPACINGdiagSpacing;] [DIAGMINEDGELENGTHdiagLength;] [AREAminArea;] [MINSIZEminWidthminLength[minWidth2minLength2] ... ;] [ [SPACINGminSpacing[ RANGEminWidth maxWidth[ USELENGTHTHRESHOLD | INFLUENCEvalue[RANGEstubMinWidthstubMaxWidth] | RANGEminWidth maxWidth] | LENGTHTHRESHOLDmaxLength[RANGEminWidthmaxWidth] ] ;] ... | [SPACINGTABLE PARALLELRUNLENGTH {length} ... {WIDTHwidth{spacing} ...} ... ; [SPACINGTABLE INFLUENCE {WIDTHwidthWITHINdistanceSPACINGspacing} ... ; ] ] ] [WIREEXTENSIONvalue; ] [MINIMUMCUTnumCutsWIDTHwidth[FROMABOVE | FROMBELOW] [LENGTHlengthWITHINdistance] ;] ... [MAXWIDTHwidth;] [MINWIDTHwidth;] [MINSTEPminStepLength[INSIDECORNER | OUTSIDECORNER | STEP] [LENGTHSUMmaxLength] ;] [MINENCLOSEDAREAarea[WIDTHwidth] ;] ... [PROTRUSIONWIDTHwidth1LENGTHlengthWIDTHwidth2;] [RESISTANCE RPERSQvalue;] [CAPACITANCE CPERSQDISTvalue;] [HEIGHTdistance;] [THICKNESSdistance;] [SHRINKAGEdistance;] [CAPMULTIPLIERvalue;] [EDGECAPACITANCEvalue;] [SLOTWIREWIDTHminWidth;] [SLOTWIRELENGTHminLength;] [SLOTWIDTHminWidth;] [SLOTLENGTHminLength;] [MAXADJACENTSLOTSPACINGspacing;] [MAXCOAXIALSLOTSPACINGspacing;] [MAXEDGESLOTSPACINGspacing;] [SPLITWIREWIDTHminWidth;] [MINIMUMDENSITYminDensity;] [MAXIMUMDENSITYmaxDensity;] [DENSITYCHECKWINDOWwindowLengthwindowWidth;] [DENSITYCHECKSTEPstepValue;] [FILLACTIVESPACINGspacing;] [ANTENNAMODEL {OXIDE1 | OXIDE2 | OXIDE3 | OXIDE4} ;] ... [ANTENNAAREARATIOvalue;] ... [ANTENNADIFFAREARATIO {value| PWL ( (d1r1) (d2r2) ...) } ;] ... [ANTENNACUMAREARATIOvalue;] ... [ANTENNACUMDIFFAREARATIO {value| PWL ( (d1r1) (d2r2) ...) } ;] ... [ANTENNAAREAFACTORvalue[DIFFUSEONLY] ;] ... [ANTENNASIDEAREARATIOvalue;] ... [ANTENNADIFFSIDEAREARATIO {value| PWL ( (d1r1) (d2r2) ...) } ;] ... [ANTENNACUMSIDEAREARATIOvalue;] ... [ANTENNACUMDIFFSIDEAREARATIO {value| PWL ( (d1r1) (d2r2) ...) } ;] ... [ANTENNASIDEAREAFACTORvalue[DIFFUSEONLY] ;] ... [PROPERTYpropName propVal;] ... [ACCURRENTDENSITY {PEAK | AVERAGE | RMS} {value| FREQUENCYfreq_1 freq_2 ...; [WIDTHwidth_1 width_2 ...;] TABLEENTRIESv_freq_1_width_1 v_freq_1_width_2 ...v_freq_2_width_1 v_freq_2_width_2 ...... } ;] [DCCURRENTDENSITY AVERAGE {value| WIDTHwidth_1 width_2 ...; TABLEENTRIESvalue_1 value_2 ...} ;]
END layerName
Following are the technology file equivalents for each line of code in the routing layer in the LEF file.
The routing PITCH of a routing layer in the LEF file is mapped to the routingGrids subsection of the constraintGroups section in the technology file. The following table shows the syntax and example of the LEF and technology files.
The routing OFFSET for a routing layer in the LEF file is mapped as routingGrids in the constraintGroups section of the technology file.
MAXWIDTH is mapped as maxWidth in the spacings subsection of the constraintGroups section in the technology file.
The MAXWIDTH rule applies only for routing layers and is a float in units of um. If MAXWIDTH is specified in any other layer, following warning message is displayed:
*WARNING* MAXWIDTH can be defined only in the routing layer: Ignoring the rule for layer layerName.
PROTRUSIONWIDTH in the LEF file is mapped as protrusionWidth in the spacings subsection of the constraintGroups section in the technology file.
In LEF, width1, width2, and length are floats in units of um. The PROTRUSIONWIDTH rule applies only to the routing layer. A protrusion width must be greater than or equal to width1 if the protrusion connects to a wire having width greater than width2 and length greater than length.
MINSTEP is mapped as minStep in the spacings subsection of the constraintGroups section in the technology file. The MINSTEP rule in the LEF file specifies the minimum step size (or shortest edge length). In this rule, distance is a float in units of um and it specifies the minimum step size. The MINSTEP rule applies only to the routing layers.
WIDTH in the LEF file is mapped as minWidth in the spacings section, which is a subsection of the constraintGroups section in the technology file.
| LEF | Technology File |
|---|---|
LAYER RX |
constraintGroups( |
The AREA rule in the LEF file is mapped as minArea in the spacingRules subsection of the physicalRules section in the technology file.
The MINWIDTH statement is mapped as minWidth in the spacings section, which is a subsection of the constraintGroups section in the technology file.
Notice that the precision of the minimum width is curtailed in the technology file as compared to the LEF file.
| LEF | Technology File |
|---|---|
LAYER RX |
constraintGroups( |
The MINIMUMCUT statement is mapped as minimumCuts in the spacingTables section, which is a subsection of the constraintGroups section in the technology file.
The minimumCut rules are stored only on the cut layers in the technology file. Rules for the cut layer are temporarily stored on the current metal layer, since the cut layer would not have been created already. These rules are later moved to the cut layers.
MINENCLOSEDAREA in the LEF file maps to the minHoleArea in the spacingTables subsection of the constraintGroups section in the technology file.
In the MINENCLOSEDAREA construct, area specifies the minimum area size limit for metal that encloses an empty area. It is a float in units of um^2. The width statement is optional and is a float in units of um.
This rule is connected to the slotting process. If the width is specified, then the width applies to the hole-edge starting from the outer-edge of the material surrounding the hole. There can be multiple minHoleArea rules per layer to take into account different width values.
The SPACINGTABLE rule applies only to the routing layer. In this rule,
where, length, width, and spacing are floats in units of um.
-
SPACINGTABLEPARALLELRUNLENGTHmaps asminSpacingin thespacingTablessubsection of theconstraintGroupssection in the technology file.
-
SPACINGTABLEPARALLELRUNLENGTHmaps tominInfluenceSpacingin thespacingTablessubsection of theconstraintGroupssection in the technology file.
The metal slotting and splitting values SLOTWIREWIDTH, SLOTWIRELENGTH, SLOTWIDTH, SLOTLENGTH, MAXADJACENTSLOTSPACING, MAXCOAXIALSLOTSPACING, MAXEDGESLOTSPACING, and SPLITWIREWIDTH are not stored in the technology file.
The MINIMUMDENSITY and MAXIMUMDENSITY metal filling values map minDensity and maxDensity rules in the spacingTables subsection of the constraintGroups section in the technology file.
DENSITYCHECKWINDOW is not stored. This value in the technology file is always twice the stepSize.
DENSITYCHECKSTEP is not stored. The value of stepSize is used for setting the minimum and maximum density.
The FILLACTIVESPACING statement maps to the minFillToShapeSpacing statement in the spacings subsection of the constraintGroups section in the technology file.
| LEF | Technology File |
|---|---|
LAYER RX |
constraintGroups( |
The routing direction of the routing layers is mapped to the routingDirections subsection of the layerRules section in the technology file.
The electrical rules of the routing layer in the LEF file are mapped to the techLayerProperties subsection of the layerDefinitions section in the technology file.
The possible electrical rules are areaCapacitance (for CAPACITANCE), edgeCapacitance (for EDGECAPACITANCE), sheetResistance (for RESISTANCE), height (for HEIGHT), thickness (for THICKNESS), shrinkage (for SHRINKAGE), or capMultiplier (for CAPMULTIPLIER).
The antenna rules in the routing layers are mapped to the antennaModels in the constraintGroups section in the technology file.
Transistors with different oxide thickness or doping have different process antenna ratios. Therefore, an optional keyword ANTENNAMODEL has been added to the cut and routing layers. ANTENNAMODEL has four parameters: OXIDE1, OXIDE2, OXIDE3, or OXIDE4. The default parameter for ANTENNAMODEL is OXIDE1.
ANTENNAAREAFACTOR and ANTENNASIDEAREAFACTOR are not stored in OpenAccess.
The examples from the LEF file and its corresponding technology file for ANTENAMODELS is as follows:
The AC and DC current density is mapped to the currentDensityTables subsection of the layerRules section in the technology file.
Cut Layer
Following is the syntax of the cut layer in LEF 5.6.
TYPE CUT ;
[SPACING minSpacing
[ LAYER 2ndLayerName
| ADJACENTCUTS {3 | 4} WITHIN distance]
| CENTERTOCENTER]
;] ...
[PROPERTYpropNamepropVal;] ...
[ACCURRENTDENSITY {PEAK | AVERAGE | RMS}
{ value
| FREQUENCYfreq_1freq_2... ;
[CUTAREAcutArea_1cutArea_2... ;]
TABLEENTRIES
v_freq_1_cutArea_1v_freq_1_cutArea_2...
v_freq_2_cutArea_1v_freq_2_cutArea_2...
...
} ;]
[DCCURRENTDENSITY AVERAGE
{ value
| CUTAREAcutArea_1cutArea_2... ;
TABLEENTRIESvalue_1value_2...
} ;]
[ANTENNAMODEL {OXIDE1 | OXIDE2 | OXIDE3 | OXIDE4} ;] ...
[ANTENNAAREARATIO value ;] ...
[ANTENNADIFFAREARATIO {value| PWL ( (d1 r1) (d2 r2) ...)} ;] ...
[ANTENNACUMAREARATIO value ;] ...
[ANTENNACUMDIFFAREARATIO {value| PWL ( (d1 r1) (d2 r2) ...)} ;] ...
[ANTENNAAREAFACTOR value ;] ...
Following are the technology file equivalents for each line of code of the cut layer in the LEF file.
The SPACING minSpacing statement is mapped as minSpacing in the spacings section, which is a subsection of the constraintGroups section in the technology file.
A new optional statement with ADJACENTCUTS and WITHIN has been added to the existing SPACING syntax in the cut layer. In the above syntax,
-
minSpacing and distance are floats in units of
um. - numCuts is an integer that is either three or four.
If the ADJACENTCUTS numCuts WITHIN construct is specified, minSpacing applies only when the number of cuts are three or four specified within the distance spacing.
Mapping of other rules is same for cut and routing layers. For details, see Routing Layer.
Masterslice Layer
Masterslice layers are typically polysilicon layers and are only needed if the cell MACROs have pins on the polysilicon layer. In LEF, the overlap layer is used to store geometries that represent the prboundary. The overlap layer should normally be named OVERLAP.
Implant Layer
Some new technologies require high-threshold and low-threshold cells to be combined together. This has been made possible by creating the implant layer.
Width is mapped as minWidth in the spacings section, which is a subsection of the constraintGroups section of the technology file. Similarly, spacing is mapped to the minSpacing statement in the spacings section.
BEGINEXT Statement
The LEF extension is not stored in OpenAccess. The LEF syntax is:
[BEGINEXT "tag"
extension
ENDEXT]
BUSBITCHARS Statement
The OpenAccess tools use delimiterPair to identify bus bit characters for name mapping.
BUSBITCHARS is mapped in the technology file in the techParams section, which is a subsection of the controls section.
| LEF | Technology File |
|---|---|
BUSBITCHARS "<>" ; |
controls( |
CLEARANCEMEASURE Statement
Specifies the clearance distance used for spacing rule checks.
CLEARANCEMEASURE {MAXXY | EUCLIDEAN};
In the above syntax, MAXXY uses the larger X and Y distances for spacing rule checks. Similarly, EUCLIDEAN uses Euclidean distance for spacing rule check. The default value is EUCLIDEAN.
MACRO Section
The MACRO section in the LEF file contains definitions for the macrocell models in the library. Macros are not mapped in the technology file.
DIVIDERCHAR Statement
The LEF divider character is used to set the divider character in the oaLefNS namespace.
DIVIDERCHAR is mapped in the technology file in the techParams section, which is a subsection of the controls section.
| LEF | Technology File |
|---|---|
DIVIDERCHAR "<>" ; |
controls( |
MANUFACTURINGGRID Statement
Manufacturing grid is used to control the distance between the two snap grids.
The snap grid controls pointer movement in the interactive drawing and editing modes. When the snap grid is defined, the pointer snaps to the closest grid point as you move it within the work area.
Distance between the two snap grids must be a multiple of the manufacturing grid. The value specified for the manufacturing grid should be positive. The numeric range is float.
MANUFACTURINGGRID is mapped in the technology file in the controls section.
| LEF | Technology File |
|---|---|
[ |
|
MANUFACTURINGGRID 0.0005 ; |
controls( ) ;controls |
Maximum Stacked Via
Some processes have an overall limit on the number of single-cut stacked vias that are allowed on top of each other. The MAXVIASTACK keyword has been added to limit the number of stacked vias. Currently, four stacked vias are permitted on top of each other.
The syntax of the MAXVIASTACK statement in LEF 5.6 is as follows.
[MAXVIASTACKvalue[ RANGEbottomLayertopLayer];]
| Syntax | Description |
|---|---|
|
An integer that limits the number of single stacked vias that are allowed on top of each other. |
|
MAXVIASTACK is mapped in the technology file in the viaStackingLimits section, which is a subsection of the constraintGroups section.
| LEF | Technology File |
|---|---|
# Only one MAXVIASTACK is allowed in a lef file MAXVIASTACK 3 RANGE M1 MT ; |
constraintGroups( viaStackingLimits( ... );constraintGroups |
If the specified layer names are not routing layer names, the RANGE keyword is ignored. The MAXVIASTACK should follow the layer definitions in the LEF file.
NAMESCASESENSITIVE Statement
The LEF NAMESCASESENSITIVE statement is ignored since OpenAccess is always case-sensitive. When you write LEF, always include NAMECASESENSITIVE ON. The LEF syntax is as follows:
NAMESCASESENSITIVE {ON | OFF} ;
SITE Section
The SITE section defines the types and properties of placement sites available in the library for. Each SITE section in a LEF file maps to a cell in the OpenAccess library.
SITE statements are mapped in the technology file in the scalarSiteDefs section.
SPACING Section
The SPACING section in the LEF file provides for the same net spacing rules and stacked vias.
USEMINSPACING Statement
Defines how minimum spacing is calculated for an obstruction (blockage) or pin geometries. It is mapped as the USEMINSPACINGOBS or USEMINSPACINGPIN property on the database object in the OpenAccess library.
USEMINSPACING {OBS | PIN} {ON | OFF};...
In the above syntax, OBS|PIN specifies whether the minimum spacing is applied to pin geometries or obstructions. The option ON|OFF specifies the calculation method for minimum spacing. If you specify ON, the spacing is the minimum layer spacing. By default, the value is assumed to be "OFF", in which case the property is not created.
VIA Statement
VIA is mapped in the technology file in the customViaDefs section, which is a subsection of the viaDef section.
VIARULE Statement
The VIARULE section in the LEF file specifies vias to be used at the intersection of special wires of the same net. A via rule can refer to vias that are defined elsewhere in the LEF file or generate its own vias.
VIARULE is mapped in the technology file in the viaSpecs section.
VIARULE GENERATE
In LEF, a via rule using generated vias has the following syntax:
The LEF VIARULE GENERATE objects are stored in OpenAccess by using an oaViaSpec. This is similar to the normal LEF VIARULE, however, the VIARULE GENERATE uses a single oaStdViaDef object (stored in oaViaDefArray(0)) instead of the oaCustomViaDef objects.
The generating vias section is mapped to the standardViaDefs subsection viaDefs section of the technology file.
Return to top