Generic Hypergraph Formats, rev. 1.1

I.	Introduction
II.	Hypergraphs (1 Overview. 2 .nodes, 3 .nets, 4 .wts)
III.	Extensions for master-instance hierarchy (.masters)
IV.	Addressing individual pins
V.	Examples
VI.	Executables

• allow easy mixing of attributes
• allow for reasonable defaults for missing attributes
• reduce total storage requirements (through reuse) 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., Cadence Design Systems, Inc. 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.

       HGraphWDims : file.nodes file.nets [file.wts] 

       HGraph : file.nodes file.nets [file.wts] 

        UCLA nets  1.0
        UCLA wts   1.0
        UCLA nodes 1.0

        # Date:  
        # Author:  

II.2. The .nodes format

The .nodes file specifies the name and other optional information about each node in the hypergraph. Each line specifies a single node. After the standard header, the format specifies:

NumNodes : total number of nodes
NumTerminals : number of terminal (pad etc.) nodes

Then, one line for each node with format as follows:

nodeName   [ nodeDimensions (default (0,0)]   [ : symmetry (default none)]   [ terminal (default is non-terminal)]

nodeName

is an arbitrary-length alpha-numeric string, which may include any number of characters from: {(a-z), (A-Z), (0-9), '_', '/', '\', '+' and '-'} node names are case-sensitive.

nodeDimensions

is a pair of white-space separated doubles indicating width, then height when in N orientation.

symmetry

specifies the axes about wihch the node may be flipped. Symmetry is given as any combination (in any order) of 'X', 'Y' and 'R90'. R90 means the node may be rotated 90 degrees. If no symmetry is present, the node is assumed to be not flippable.

``terminal''

is a literal that indicates that the node is a terminal

Standard header (as specified in section I.2)
NumNets : total number of nets
NumPins : total number of net-node connections

followed by at least total number of number of nets   netSpecifications that list all nodes incident to each individual net.

Each netSpecification consists of:

NetDegree : number of pins on the net [netName]
nodeName1 [pinDirection] [: pinOffset]
nodeName2 [pinDirection] [: pinOffset]
....
nod3NameN [pinDirection] [: pinOffset]

Net names should comply with the same restrictions as node names (above) but are optional. Unnamed nets may be assigned default names by the parser - 27-th net should be named NET27 etc (even if some nets 1-27 were named). If this collides with other named nets, the parser should add lowercase letters until it finds an available name (e.g., NET27a, NET27b,.. NET27aa etc). Note that checks for name clashes may need to be performed atfer all names nets are parsed.

If the number of nodeNames does not match the netDegree, a fatal parser error should occur with a relevant error message printed. A nodeName may appear more than once for the same net. This indicates multiple connections to a node. This functionality is intended to support block placement, but is not very essential in standard cell placement, in which case it is acceptable to ignore all but the first incidence of a node.

The optional pinDirection is given exactly as in the .netD format. (I for input, O for output, B for bidirectional)

A .nets parser should additionally check for an optional colon (:) separated by blanks as the next word. If the colon is not found, everything is ignored until the end of the line, and the pin is placed at the center of the node.

If the slash is found, two doubles are expected, separated by blanks - x and y pin offset from the origin (center) of the node. Each double can start with a percent sign, in which case it is relative to 1/2 of the respective (X or Y) dimension of the respective node (this is useful for soft macros in floorplanning).

where nodeName and netName use characters allowed for nodenames in .nodes files. Net names may be default net names (e.g., NET27) that generated when reading .nets files. Each weight is a double.