SPEF Files Explained

SPEF Files Explained

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

  1. All keywords in SPEF start with an asterisk (*), followed by all capital or underscore. e.g. `*D_NET`
  2. Keywords, identifiers, characters, and numbers are delimited by syntax characters, white_space, 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 pin_delim (*DELIMITER) between an instance and pin name, such as : in I\$481:X
    2. The heir_delim (*DIVIDER) character, such as / in /top/coreblk/cpu1/inreg0/I\$481
    3. A prefix_bus_delim or suffix_bus_delim (*BUS_DELIMITER) being used to denote a bit of a logical bus or an arrayed instance, such as DATAOUT[12]
  4. SPEF file synatx is `SPEF_file ::= header_def [name_map] [power_def] [external_def] [define_def] [variation_def] internal_def` A spef file can have the follwing sections
    • Header Section : header_def
    • Name map definition : [name_map]
    • Power & Ground Nets definition : [power_def]
    • External definition : [external_def]
    • Hierarchical SPEF (entities) definition : [define_def]
    • Process and temperature variation definition : [variation_def]
    • Internal definition : internal_defNot all of these are mandatory, and I will be talking in detail about a typical SPEF file that has a header section, name_map, ports section(external_def) and the parasitic definition section(internal_def).
  5. // 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 design_name, 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 : `*T_UNIT ,*C_UNIT , *R_UNIT, *L_UNIT`

Name map definition Name map section starts with the Keyword "*NAME_MAP". 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.

*NAME_MAP

*1 o_vcm0_s[0] *2 o_vcm0_b[2] *3 o_vcm0_b[1] ..... *214 i_comp_lat_ehpf *215 i_comp_etot ..... *5916 U67

Subsequently in the parasitic definition sections, `o_vcm0_s[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 `o_vcm0_s[0] & o_vcm0_b[2]` are output ports, whereas `i_comp_etot & i_comp_lat_ehpf` 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 `*D_NET` statement. If it is an `*R_NET` , you have a reduced net definition. I am going to explain the `*D_NET` in this section, as it is the most common in design flow.

The syntax for `*D_NET` specification is `d_net ::= *D_NET net_ref total_cap [routing_conf] [conn_sec] [cap_sec] [res_sec] [induc_sec] *END` A typical example is

*D_NET *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 name_map section gives the net name as `i_comp_lat_ehpf`.

  • 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: `conn_def ::= *P external_connection direction {conn_attr} | *I internal_connection direction {conn_attr}`

    • `*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 D_NET `*214` as port `*214` and `*5916:A`. From name_map section, `*5916` is mapped to the instance `U67`. So are looking at the parasitics of net `i_comp_lat_ehpf` which has port `i_comp_lat_ehpf` 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 *C_UNIT).

  • The *CAP definition gives detailed capacitance of the net. If lumped to ground, the `cap_elem` 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` (i_comp_lat_ehpf) , 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 *R_UNIT). The resiatnce section will grow with the number of fanouts.

  • `*END` denotes the end of parasitic definition for the `*D_NET`. The `*D_NET` section for the next net starts after the `*END` statement.

parasitics spef timing