MARCO GSRC Calibrating Achievable Design: Bookshelf

Placement Slot (see other slots)

Placement Formats, rev. 1.2

Work in progress: last updated Sat Nov 20 1999

Andrew Caldwell Andrew B. Kahng Igor Markov

The proposed file formats flexibly capture seeral traditional problem formulations in standard-cell placement and partitioning. We maximized the ease of use and modularity. One normally does not need to specify information beyond what's needed in a particular context, since our formats define reasonable defaults for unspecified data. Constructing parsers should be straightforward, assuming that a hash_map implementation is available (e.g., as in g++2.95). Parsers may choose not to implement some of the features below, in which case they should issue relevant error messages when they encounter such unimplemented features. We plan to make publiclly available a suite of binary utilities and, possibly, a parser.

Contents

I.	Introduction (1 General. 2 Placement Formats)
II.	Hypergraphs with pins (.nodes, .nets, .wts)
III.	Standard cell layout (SCL) (1. Overview 2. .scl files)
IV.	Placement and orientation (.pl)
V.	Extensions for master-instance hierarchy (.masters)
VI.	Addressing individual pins
VII.	Examples
VIII.	Conclusions and futures

I.1. General

We are motivated by the desires to

• allow easy mixing of attributes
• allow for missing attributes
• reduce storage requirements if many combinations of the same attributes are of interest

    Format name  :  filename1  filename2   ...   filenameN

Format name   must be recognized by the reader software and the following filenames must have recognizable suffixes. Filenames can be mentioned in an arbitrary order and will be processed in the order relevant for a given multi-file format. We also allow CD command in .aux files (a "command" is the word that precedes the colon) for changing the current directory and will publish relevant system-independent specifications if there is interest to them.

The following agreements are common for all component and aux files

• blank characters are spaces and tabs.
• multiple blank characters are equivalent to one
• a colon (:) must always be preceded and followed by a space
• the pound sign (#) denotes commented out lines and is only guaranteed to be processed correctly if all characters earlier on the line are blank characters
• when the tokens expected to be found on the line are successfully parsed, all characters until the end of the line must be ignored (this allows for easy extensions); a one-time warning must be issued by the parser if any non-blank characters were ignored: "Non-blank characters are ignored until the end of line XXX and, possibly, later".
• if the line-end character is encountered before all tokens are parsed, a fatal error message "Unexpected line end on line XXX" must be generated.
• all units with dimensions, such as locations, offsets, sizes, weights etc, can be specified as doubles. It is possible to use integers, but we felt that restricting to integers may be too risky as, e.g., LEFDEF specifies doubles. We believe that resolving 3.000000 vs 2.99999 (that may arise if a particular program expects an integer) is not difficult via rounding to integers and checking with a reasonably small round-off tolerance. This should be done by the programs that save doubles (i.e., test if a number to be saved is epsilon-close to an integer, and if it is, round it up before saving). Physical design tools that use floats internally (less memory needed than when using doubles) should read doubles and check for overflows during conversion to floats.

I.2. File formats for placement

The purpose of the placement formats detailed here is to support research and exchange of techniques on fundamental VLSI-CAD problems. In particular, these formats should support:

• the traditional 'pure hypergraph partitioning' model, as well as more recent versions with (possibly many) varying weights, terminals and geometric cost functions
• global placement of standard cells
• block placement

The placement file formats are described as follows (by extension)

• .nodes, .nets, .wts (see section II) - hypergraphs with pins, dimensions, and multiple weights
• .scl files (see section III) - - standard cell layout
• .pl files (see section IV) - cell locations and orientations

      STDCellPlacement : test.nodes test.nets test.wts test.scl test.pl  

In this version of the format all rows are assumed to be horizontal core rows. Additional row types, e.g., vertical pad rows, will be possible in future revisions.

2. The .scl format

.scl files begin with a line mentioning the format name and revision, e.g.

        UCLA scl 1.0

        # Date:  
        # Author:  

The .scl file format is essentially a template, and therefore can be explained using a sample file. This example declares 2 rows - the parser must read 2 rows and ignore whatever follows. Failing to parse 2 row declarations should result in a fatal error.

"CoreRow Horizontal"

currently all rows are corerows and horizontal.

"Coordinate"

is interpreted as "Y" for the "Horizontal" declaration, and may be interpreted as "X" if "Vertical" is added in the future.

"Height"

optional, defaults to 0. Subrows of different rows may overlap if considered as rectangles with hight.

"Sitewidth"

optional, defaults to "Sitespacing".

"Sitespacing"

is measured in absolute units and is the distance between the beginnings of neighboring sites in subrow.

"Siteorient"

optional, defaults to N. May take the same values as cell orientation and gives of orientations that are allowed for cells in a given row.

"Sitesymmetry"

optional, defaults to none (blank). May take the same values as cell symmetry in the specification of hypergraph with pins. Applied to site orientation, produces all orientations allowed for a cell in a given row.

"SubrowOrigin"

declares a subrow and may appear arbitrarily many times inside a row declaration. It is followed by the absolute value of the subrow's origin. For a horizontal row/subrow, this is the X coordinate. The origin coordinate must be followed on the same line by "Numsites : " and an integer.

Orientations : the default orientation is "vertically and face up" - N (North). Rotate by 90deg clockwise to get E, S and W, flip to get FN, FE, FS and FW. (think of a dial).

Placement files start with a line mentioning the format name and revision,

        UCLA pl   1.0

        # Date:  
        # Author:  

cellname info

in any order; lines with all blanks are ignored. In .pl files, represents x and y location of a cell (in that order; floating point values) and may have an optional blank-separated slash (/) followed by a one- or two-letter case-insensitive specification of the cell's spatial orientation (N for north, S for south, E, W, and FN, FS, FE, FW for "flipped" orientations). N is the default and means that the pin offsets are exactly as specified in the .nets file. Another optional slash may be followed by the word FIXED, with the straightforward meaning.

A recent addition is an optional DIMS=(dx,dy) that can be used to express floorplanning solutions for soft blocks.

While we consider the abstract syntax relatively solid, concrete syntax (data formats) will be detailed over the next few days (Nov 22-24, 1999).

Notes:

1. Physically identical placements may be specified by difft orientations in the .pl file if the respective .nets files were different.
2. The standard cell layout format may restricts possible cell orientations in rows (as a placement constraint).

Examples

Extensions to be added soon include:

• Provisions for spacial constraints

caldwell@cs.ucla.edu,abk@ucsd.edu,imarkov@ucsd.edu