###
LEF/DEF 5.8 Language Reference

# 3

# Working with LEF

This chapter contains information about the following topics.

| Incremental LEF

| Error Checking

## Incremental LEF

INPUT LEF can add new data to the current database, providing an incremental LEF capability. Although it is possible to put an entire LEF library in one file, some systems require that you put certain data in separate files.

This feature also is useful, for example, when combined with the INPUT GDSII command, to extract geometric data from a GDSII-format file and add the data to the database.

When using INPUT LEF on a database that has been modified previously, save the previous version before invoking INPUT LEF. This provides a backup in case the library information has problems and the database gets corrupted or lost.

|  | The original LEF file, created with FINPUT LEF (or with INPUT LEF when no database is loaded), must contain all the layers.

#### Adding Objects to the Library

INPUT LEF can add the following objects to the database:

| New via

| New via rule

| Samenet spacings (if none have been specified previously)

| New macro

If geometries have not been specified for an existing via, INPUT LEF can add layers and associated rectangle geometries. If not specified previously for a macro, INPUT LEF can add the following:

| FOREIGN statement

| EEQ

| LEQ

| Size

| Overlap geometries

| Obstruction geometries

If not previously specified for an existing macro pin, INPUT LEF can add the following:

| Mustjoins

| Ports and geometries

The database created by INPUT LEF can contain a partial library. Run VERIFY LIBRARY before proceeding.

If new geometries are added to a routed database, run VERIFY GEOMETRY and VERIFY CONNECTIVITY to identify new violations.

|  | When defining a pin with no port geometries with the intent of incrementally adding them, do not include an empty PORT statement as shown below.

MACRO abc
  ...
  PIN a
  ...
  PORT # dummy pin-port, do not
  END # include these two lines
  END a
  ...

## Error Checking

To help develop, test, and debug generic libraries and parametric macros, LEF and DEF have a user-defined error checking facility. This facility consists of seven utilities that you can use from within a LEF or DEF file during the scanning phase of LEF/DEF readers. These utilities have the following features:

| A message facility that writes to one or more text files during LEF or DEF input

| An error handling facility that logs user detected warnings, errors, and fatal errors

The error checking utilities have the following syntax:

&CREATEFILE &fileAlias =
{ stringExpression
| stringIF-ELSEexpression } ;

&OPENFILE &fileAlias ;

&CLOSEFILE &fileAlias ;

&MESSAGE
{&fileAlias | &MSGWINDOW} = message;

&WARNING
{&fileAlias | &MSGWINDOW} = message ;

&ERROR
{&fileAlias | &MSGWINDOW} = message ;

&FATALERROR
{&fileAlias | &MSGWINDOW} = message;

message =
{ &fileAlias | stringExpression
| stringIF-ELSEexpression
| stringIFexpression }

### Message Facility

The message facility outputs user-defined messages during the scanning phase of LEF and DEF input. These messages can be directed to the message window.

#### &CREATEFILE

The &CREATEFILE utility first assigns a token (&fileAlias) to represent a named file. The file name is derived from a previously defined string, a quoted string, or an IF-ELSE expression that evaluates to a string. The following example illustrates these three cases.

&DEFINES &messagefile = "demo1.messages" ;
&CREATEFILE &outfile = &messagefile ;
&CREATEFILE &msgs =
"/usr/asics/cmos/fif4/errors.txt" ;
&CREATEFILE &messages =
IF &errortrap
THEN "errs.txt"
ELSE "/dev/null" ;

The derived file name must be a legal file name in the host environment. The default directory is the current working directory. The file names are case sensitive.

&CREATEFILE creates an empty file with the given name and opens the file. If the token is already bound to another open file, a warning is issued, the file is closed, and the new file is opened. If the file already exists, the version number is incremented.

#### &CLOSEFILE and &OPENFILE

The &CLOSEFILE utility closes the file bound to a given token; &OPENFILE opens the file bound to a given token. &CLOSEFILE and &OPENFILE control the number of open files. Each operating system has a limit for the number of open files. Therefore, &CLOSEFILE might be needed to free up extra file descriptors.

Files are closed in the following ways.

| All user files are closed at the end of the scanning phase of the LEF and DEF readers.

| All user files are closed if the scanning phase aborts.

| If &CREATEFILE is invoked with a token that is already bound to an open file, that file is closed before opening the new file.

#### &MESSAGE

The &MESSAGE utility appends text to the file represented by the &fileAlias token, or to the message window if &MSGWINDOW is specified.

&MSGWINDOW is a special file alias that is not created, opened, or closed. The assigned expression (right side of the statement) can be one of the following:

&fileAlias

> Must correspond to a valid file that has been successfully opened. The contents of the file are appended to the target file (or message window).

stringExpression

> Either a string or a string token.
> For example:

&DEFINES &romword16 =
"ROM word size = 16 bits" ;
&MESSAGE &mesgs = "ROM size = 256" ;
&MESSAGE &mesgs = &romword16 ;

stringIF-ELSEexpression

> String IF-ELSE expressions evaluate a Boolean expression and then branch to string values, for example:

&&MESSAGE &mesgs =
IF (&&c_flag = 0)
THEN "FLAG C set to 0"
ELSE IF ( &&c_flag = 1 )
THEN "FLAG C set to 1"
ELSE "FLAG C set to 2" ;

> As shown in this example, IF-ELSE expressions can be nested.

stringIFexpression

> A string IF expression is an IF-ELSE expression without the ELSE phrase. The Boolean expression is evaluated, and if true, the THEN string is sent to the target file; if false, no string is sent, for example,

&MESSAGE &mesgs =
IF ( &&buf = "INV_BIG" )
THEN "INV_BIG buffers" ;

Neither the file alias token nor &MSGWINDOW can be part of the assigned expression.

### Error-Checking Facility

In addition to the message facility, you have partial control of the error checking facility of the LEF and DEF readers. When scanning LEF or DEF input, the readers record warnings, errors, and fatal errors. At the end of the scan, the total number of each is sent to the message window before proceeding with the reader phase.

If a fatal error is detected, input is aborted after the scanning phase.

With the user interface to the error checking facility, the LEF and DEF files can include custom error checking. User detected warnings, errors, and fatal errors, can be logged, thereby incrementing the DEF/LEF reader's warning, error, and fatal error counts.

A user-detected fatal error terminates input just as with the resident error checking facility. In addition, the user defined error checking facility utilities can send message strings to the message window.

#### &WARNING, &ERROR, and &FATALERROR

The &WARNING, &ERROR, and &FATALERROR utilities use the same syntax as the &MESSAGE utility. These utilities can send message strings to files and to the message window in the same manner as &MESSAGE. In addition, when the assigned expression is a string IF expression, or a string IF-ELSE expression, then the associated counter (warnings, errors, or fatal errors) is incremented by 1 if any IF condition evaluates to true.

Return to top of page

For support, see Cadence Online Support service.
Copyright © 2016, Cadence Design Systems, Inc.
All rights reserved.