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. Introduction and overview

The proposed formats are designed to be simple and easily human readable, as well as conveniently parsable. For this purpose, we have specifically decided not to include such details as inter-node geometries or hierarchies (though, it is possible to embed hierarchies in node names). If such level of detail is required, existing industry standard file formats (LEFDEF, TW etc) can be used.

I.1. General

We are motivated by the desires to

Therefore, we distribute placement information over several component files. To assemble multiple component files into problem instances, we use .aux files that typically include one line of the form

    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

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:

We are aware of previous benchmarking efforts, especially those by MCNC (F. Brglez et all) and C. Alpert. Whenever we depart from those formats, this is mainly to ensure additional ease of use or flexibility.

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

All legal combinations of files can be specified in a one-line .aux file that defines a placement instance by mentioning the above files in no particular order (the parsing order is fixed and does not depend on the order in which files are mentioned), e.g., 
      STDCellPlacement : test.nodes test.nets test.wts test.scl test.pl
Specified files are parsed in a predefined order that is determined by their extensions (not the order in .aux file) - .nodes, .nets, .wts, .scl, .pl.
II. Hypergraphs with pins

See the Hypergraph slot (follow links to "old formats", i.e., no XML)
III. Standard cell layout (SCL)

1. Overview The [single] file format for standard cell layout represents configurations of individual rows in a standard cell layout. Configurations of rows supply constraints for cell placement. Every row consists of non-overlapping subrows that are aligned at the coordinate of the row. Subrows can only differ by their origin and the number of sites. All subrows in a row share the following attributes of their row: The interpretations of these attributes are given in the next section (see also the .pl and .nets format descriptions below for cell orientations and symmetries).

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
and are typically followed by commented out lines with info about the origin of the file 
        # Date:  
        # Author:
and the like.

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.
Allowed orientations of a cell in sites of a given row are treated as a placement constraint and must be compared to the allowed orientations of a given cell (i.e., cell's symmetries applied to cell's default orientation). Placement without orientation consideration can be represented by defaults (N) of orientations and constraints both in the layout and hypergraph with pins.
IV. Placement and orientations (.pl format)

The single-file placement format represents (x,y)-placement of cells (may be undefined for some cells), optional fixed status and optional spatial orientation of each cells. Files in placement format have extension .pl and are to be used with standard cell layuot (.scl) files and [multi-file] specifications of hypergraph with pins.

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
and are typically followed by commented lines with info about the origin of the file 
        # Date:  
        # Author:
and the like. The body contains a declaration of the number of cells (including pads) (XXX to be filled) followed by lines of the form

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

V. Extensions for master-instance hierarchy(.masters)

See the Hypergraph slot.

VI. Addressing individual pins

See the Hypergraph slot.

VII. Examples

VIII. Conclusions and futures

We believe that our general guidelines can be used in a wide variety of other instance formats for fundamental problems in VLSI and are otherwise conducive of improved collaboration between researchers. Benchmark suites in proposed formats will be provided.

Extensions to be added soon include:

Back to Bookshelf Slots

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