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.

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_def

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