SPEF Files Explained

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.

Structure

1. All keywords in SPEF start with an asterisk (*), followed by all capital or underscore. e.g. *DNET
2. Keywords, identifiers, characters, and numbers are delimited by syntax characters, whitespace, or newline.
3. 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:
   1. The pindelim (*DELIMITER) between an instance and pin name, such as : in I\$481:X
   2. The heirdelim (*DIVIDER) character, such as /in/top/coreblk/cpu1/inreg0/I\$481
   3. A prefixbusdelim or suffixbusdelim (*BUSDELIMITER) being used to denote a bit of a logical bus or an arrayed instance, such as DATAOUT[12]
4. 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).
5. // begins a single-line comment anywhere on the line, which is terminated by a newline. /* begins a multiline comment, terminated by */

Syntax

• 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 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.90410 line 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. Syntax: 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 we 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.