SPEF Files Explained
Last modified 2012-10-31
Sini
ol {padding-left:20px;} Standard Parasitic Exchange Format(SPEF) is an IEEE format for specifying chip parasitics. The specification for SPEF is a part of standard 1481-1999 IEEE Standard for Integrated Circuit (IC) Delay and Power Calculation System . Latest version of SPEF is part of 1481-2009 IEEE Standard for Integrated Circuit (IC) Open Library Architecture (OLA) . The SPEF provides a standard medium to pass parasitic information between EDA tools during any stage in the design process.
Syntax
- All keywords in SPEF start with an asterisk (*), followed by all capital or underscore. e.g. `*DNET`
- Keywords, identifiers, characters, and numbers are delimited by syntax characters, whitespace, or newline.
- Any character other than alphanumerics and underscore () shall be escaped when used in an identifier in a SPEF file. However there are exceptions to the escape rule as follows:
- The pindelim (*DELIMITER) between an instance and pin name, such as : in I\$481:X
- The heirdelim (*DIVIDER) character, such as / in /top/coreblk/cpu1/inreg0/I\$481
- A prefixbusdelim or suffixbusdelim (*BUSDELIMITER) being used to denote a bit of a logical bus or an arrayed instance, such as DATAOUT[12]
- SPEF file synatx is `SPEFfile ::= headerdef [namemap] [powerdef] [externaldef] [definedef] [variationdef] internaldef` A spef file can have the follwing sections
- Header Section : headerdef
- Name map definition : [namemap]
- Power & Ground Nets definition : [powerdef]
- External definition : [externaldef]
- Hierarchical SPEF (entities) definition : [definedef]
- Process and temperature variation definition : [variationdef]
- Internal definition : internaldefNot all of these are mandatory, and I will be talking in detail about a typical SPEF file that has a header section, namemap, ports section(externaldef) and the parasitic definition section(internaldef).
- // begins a single-line comment anywhere on the line, which is terminated by a newline. /* begins a multiline comment, terminated by */
Header Section The header section has information on designname, extrcation tool, units etc. Some of the keywords in header are given below. - Spef version : `*SPEF` - Design Name: `*DESIGN` - RC EXtrcation tool : `*PROGRAM` - Hierarchy delimiter : `*DIVIDER` - Bus delimiter : `*DELIMITER` - Units : `*TUNIT ,*CUNIT , *RUNIT, *LUNIT`
Name map definition Name map section starts with the Keyword "*NAMEMAP". This is an optional section, and is used to reduce the filesize by mapping the long names into shorter numbers preceeded by an asterisk. (*). e.g.
*NAMEMAP
*1 ovcm0s[0] *2 ovcm0b[2] *3 ovcm0b[1] ..... *214 icomplatehpf *215 icompetot ..... *5916 U67
Subsequently in the parasitic definition sections, `ovcm0s[0]` will be referred by `*1` and so on.
External definitions (`*PORTS`) We are interested in the ports as defined by the SPEF. Search for `*PORTS` in the spef file.
*PORTS
*1 O *2 O ..... *214 I *215 I
When read together with the name map section, this means `ovcm0s[0] & ovcm0b[2]` are output ports, whereas `icompetot & icomplatehpf` are an input ports of the design as specified by the `*DESIGN` construct.
Internal Definition This section gives detailed net definition OR reduced net definition. After the `*PORTS` section, you will usually have a `*DNET` statement. If it is an `*RNET` , you have a reduced net definition. I am going to explain the `*DNET` in this section, as it is the most common in design flow.
The syntax for `*DNET` specification is `dnet ::= *DNET netref totalcap [routingconf] [connsec] [capsec] [ressec] [inducsec] *END` A typical example is
*DNET *214 9.90410
*CONN *P *214 I *C 0.00000 91.0500 *I *5916:A I *C 61.5500 92.7500 *L 7.70000
*CAP 1 *214 7.56297 2 *5916:A 2.34113
*RES 1 *214 *5916:A 20.1528 *END
-
The
*D_NET *214 9.90410line refers to the netname and the total cap of the net. Looking up `*214` in namemap section gives the net name as `icomplatehpf`. -
The `*CONN` section gives the external & internal connection to the net. Connection to a port is an external connection and is denoted by `*P`. An internal connection is to the pin of a cell and start with an `*I`. Syntaxc: `conndef ::= *P externalconnection direction {connattr} | *I internalconnection direction {connattr}`
- `*P *214 I` : This means the direction is input. Can have `I, O or B`, depending on whther the port/pin is input, output or bidirectional.
- `*C 0.00000 91.0500` : Gives the coordinates
- `*L` gives the capacitance load value. If a driver, `*D` will give the driving cell name.
The snippet
*CONN *P *214 I *C 0.00000 91.0500 *I *5916:A I *C 61.5500 92.7500 *L 7.70000
gives the connections of the DNET `*214` as port `*214` and `*5916:A`. From namemap section, `*5916` is mapped to the instance `U67`. So are looking at the parasitics of net `icomplatehpf` which has port `icomplatehpf` as the driver and a single fanout of `U67/A`. The load cap as seen by the net at pin `U67/A` is `7.70000`(unit as specified in *CUNIT).
-
The *CAP definition gives detailed capacitance of the net. If lumped to ground, the `capelem` has only one node, but can have two nodes if coupled capacitance. The example above is for capacitance lumped to ground.
1 *214 7.56297
Cap element 1 is for the node `*214` (icomplatehpf) , and it has a capacitance of `7.56297units`. The capacitance section will grow with the number of fanouts.
-
*RES Section The `*RES` section provides the resistance for the net. `1 *214 *5916:A 20.1528` specifies that between the nodes `*214` and `*5916:A`, the resiatnce is `20.1528units`(as specified by *RUNIT). The resiatnce section will grow with the number of fanouts.
-
`*END` denotes the end of parasitic definition for the `*DNET`. The `*DNET` section for the next net starts after the `*END` statement.