Standard Parasitic Exchange Format

Standard Parasitic Exchange Format (SPEF) is an IEEE standard for representing parasitic data of wires in a chip in ASCII format. Non-ideal wires have parasitic resistance and capacitance that are captured by SPEF. These wires also have inductance that is not included in SPEF. SPEF is used for delay calculation and ensuring signal integrity of a chip which eventually determines its speed of operation.
SPEF is the most popular specification for parasitic exchange between different tools of EDA domain during any phase of design.
The specification for SPEF is a part of the 1481-1999 IEEE Standard for Integrated Circuit (IC) Delay and Power Calculation System. The latest version of SPEF is part of 1481-2009 IEEE Standard for Integrated Circuit (IC) Open Library Architecture (OLA) .
SPEF is extracted after routing in Place and route stage. This helps in the accurate calculation of IR-drop analysis and other analysis after routing. This file contains the R and C parameters depending on the placement of a tile/block and the routing among the placed cells.
SPEF syntax.
SPEF (Standard Parasitic Extraction Format) is documented in chapter 9 of IEEE 1481-1999. Several methods of describing parasitics are documented, but we are discussing only a few important ones.
General Syntax.
A typical SPEF file will have 4 main sections:
Generally, SPEF keywords are preceded with an asterisk, for example: codice_1, codice_2 and codice_3.
Comments start anywhere on a line with codice_4 and run to the end of the line. Each line in a block of comments must start with codice_4.
Header Information.
The header section is 14 lines containing information about:
When reading SPEF, it is important to check the header for units as they vary across tools. By default, SPEF from Astro will be in pF and kΩ while SPEF from Star-RCXT and Quantus QRC will be in fF and Ω.
Name Map Section.
To reduce file size, SPEF allows long names to be mapped to shorter numbers preceded by an asterisk. This mapping is defined in the name map section. For example:
Later in the file, codice_6 can be referred to by its name or by codice_7. Name mapping in SPEF is not required. Also, mapped and non-mapped names can appear in the same file. Typically, short names such as a pin named A will not be mapped as mapping would not reduce file size. You can write a script will map the numbers back into names. This will make SPEF easier to read, but greatly increase file size.
Port Section.
The port section is simply a list of the top level ports in a design. They are also annotated as input, output or bidirect with an I, O or B. For example:
Parasitics.
Each extracted net will have a codice_3 section. This will usually consist of a codice_3 line, a codice_10 section, a codice_11 section, codice_12 section, and an codice_13 line. Single pin nets will not have a codice_12 section. Nets connected by abutting pins will not have a codice_11 section.
1 regcontrol_top/GRC/U9743:E 0.936057
2 regcontrol_top/GRC/U9409:A regcontrol_top/GRC/U10716:Z 0.622675
3 regcontrol_top/GRC/U9407:Z 0.386093
1 regcontrol_top/GRC/U9743:E regcontrol_top/GRC/U9407:Z 10.7916
2 regcontrol_top/GRC/U9743:E regcontrol_top/GRC/U9409:A 8.07710
3 regcontrol_top/GRC/U9409:A regcontrol_top/GRC/U9407:Z 11.9156
The codice_3 line tells the net name and the net's total capacitance. This capacitance will be the sum of all the capacitances in the codice_11 section.
*CONN Section.
The codice_10 section lists the pins connected to the net. A connection to a cell instance starts with a codice_19. A connection to a top level port starts with a codice_20.
The syntax of the codice_10 entries is:
 *I <pin name> <direction> *C <xy coordinate> <loading or driving information>
Where:
*CAP Section.
The codice_11 section provides detailed capacitance information for the net. Entries in the codice_11 section come in two forms, one for a capacitor lumped to ground and one for a coupled capacitor.
A capacitor lumped to ground has three fields:
Example.
 1 regcontrol_top/GRC/U9743:E 0.936057
A coupling capacitor has four fields:
Example.
 2 regcontrol_top/GRC/U9409:A regcontrol_top/GRC/U10716:Z 0.622675
If net codice_30 is coupled to net codice_24, the coupling capacitor will be listed in each net's codice_11 section.
*RES Section.
The codice_12 section provides the resistance network for the net.
Entries in the codice_12 section contain 4 fields:
Example.
 1 regcontrol_top/GRC/U9743:E regcontrol_top/GRC/U9407:Z 10.7916
The resistance network for a net can be very complex. SPEF can contain resistor loops or seemingly ridiculously huge resistors even if the layout is a simple point to point route. This is caused by the extraction tool cutting nets into tiny pieces for extraction and then mathematically stitching them back together when writing SPEF.
Parasitic Values.
The above examples show a single parasitic value for each capacitor or resistor. It is up to the parasitic extraction and delay calculation flow to decide which corner this value represents. SPEF also allows for "min":"typ":"max" values to be reported:
 1 regcontrol_top/GRC/U9743:E 0.936057:1.02342:1.31343
The IEEE standard requires either 1 or 3 values to be reported; however, some tools will report "min":"max" pairs and it is expected that tools may report many corners ("corner1":"corner2":"corner3":"corner4") in the future.
The Difference Between Parasitic Data Formats.
SPEF is not the same as SPF (including DSPF and RSPF). Detailed Standard Parasitic Format is a very different format, meant to be useful in a SPICE simulation. For example, codice_35 sections do not have endings, and comments should start with two asterisks.
A brief syntax of the DSPF format is as shown below.
.SUBCKT
.ENDs
.END
The acronyms stand for:
SPF is a Cadence Design Systems standard for defining netlist parasitics. DSPF and RSPF are the two forms of SPF; the term SPF itself is sometimes used (or misused) to represent parasitics in general. DSPF and RSPF both represent parasitic information as an RC network. RSPF represents each net as an RC "pi" model, which consists of an equivalent "near" capacitance at the driver of the net, an equivalent "far" capacitance for the net, and an equivalent resistance connecting these two capacitances. Each net has a single "pi" network for the network, regardless of how many pins are on the net. In addition to the pi network, RSPF causes the PrimeTime tool to calculate an Elmore delay for every pin-to-pin interconnects delay.
In contrast, DSPF models a detailed network of RC parasitics for every net. DSPF is therefore more accurate than RSPF, but DSPF files can be an order of magnitude larger than RSPF files for the same design. In addition, there is no specification for coupling caps in DSPF. DSPF is more similar to a SPICE netlist than the other formats. SPEF is an Open Verilog Initiative (OVI) — and now IEEE — format for defining netlist parasitics. SPEF is "not" identical to the SPF format, although it is used in a similar manner. Like the SPF format, SPEF includes resistance and capacitance parasitics. Also like the SPF format, SPEF can represent parasitics in detailed or reduced (pi-model) forms, with the reduced form probably being more commonly used. SPEF also has a syntax that allows the modeling of capacitance between different nets, so it is used by the PrimeTime SI (crosstalk) analysis tool. SPEF is smaller than SPF and DSPF because the names are mapped to integers to reduce file size.
SBPF is a Synopsys binary format supported by PrimeTime. Parasitic data converted to this format occupies less disk space and can be read much faster than the same data stored in SPEF format. You can convert parasitics to SBPF, by reading them in and then writing them out with the codice_36 command.